IPP> SEC - Security parameters for IPP scheme

IPP> SEC - Security parameters for IPP scheme

Paul Moore paulmo at microsoft.com
Fri Aug 7 17:57:03 EDT 1998


So the requirement is that we be able to use TLS. I'm just trying to
understand the goal here.

> -----Original Message-----
> From:	Carl-Uno Manros [SMTP:manros at cp10.es.xerox.com]
> Sent:	Friday, August 07, 1998 1:33 PM
> To:	Paul Moore; ipp at pwg.org
> Subject:	RE: IPP> SEC - Security parameters for IPP scheme
> 
> Paul,
> 
> OK I will try again. A longstanding requirement is to have an alternative
> and stronger security mechanism than what is offered in RFC 2069. After a
> lot of discussion we decided that TLS met that overall IETF requirement.
> We
> also designed a simple mechanism to associate each Printer-URI with a
> particular security protocol. However, if say you only support TLS access
> on a printer how do you find that out without going through a
> trial-and-error process every time? (You can if you use SSL3 and https,
> but
> TLS does not distinguish in the scheme). 
> 
> Keith's proposal was to include that info in the form of additional
> security parameters in the ipp scheme URL (assuming that we are using ipp
> scheme URIs). The proposal tries to describe how such a solution could be
> realized. Apparently the Security ADs think that this approach could work,
> but we still have to get more detailed and official fedback from them
> before we continue. I hope to have that feedback in time for our Toronto
> meeting, so that we can discuss the subject there. Hence putting out the
> proposal now seemed appropriate so anybody who is interested in the
> subject
> can start thinking about it in time for Toronto.
> 
> Carl-Uno
> 
> At 11:49 AM 8/7/98 PDT, Paul Moore wrote:
> >Thats a proposed solution - whats the requirement?
> >
> >> -----Original Message-----
> >> From:	Carl-Uno Manros [SMTP:manros at cp10.es.xerox.com]
> >> Sent:	Friday, August 07, 1998 11:29 AM
> >> To:	Paul Moore; ipp at pwg.org
> >> Subject:	RE: IPP> SEC - Security parameters for IPP scheme
> >> 
> >> At 11:21 AM 8/7/98 PDT, Paul Moore wrote:
> >> >What is the requirement from Keith?
> >> >
> >> 
> >> To have security parameters in the ipp scheme, so you know how to map
> the
> >> ipp scheme to the underlying layer, in particular how to start off the
> >> communication with the IPP server if you use TLS.
> >> 
> >> Carl-Uno
> >> 
> >> 
> >> >> -----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
> >> >
> >> >
> >> 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
> >
> >
> 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