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@cp10.es.xerox.com]
>> Sent: Friday, August 07, 1998 11:29 AM
>> To: Paul Moore; ipp@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@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
>> >
>> >
>> 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
>
>
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