Randy
>
>> -------------------------------------------------------------------
>> Summary Conclusions
>> -------------------------------------------------------------------
>>
>> The IPP working group has serious concerns regarding integrating a new
>> "ipp:" URL into our specifications. The following issues have been
>> raised with regards to usage of the "ipp:" scheme.
>>
>> 1. There is currently no defined way for a single "ipp:" URL to
>> indicate whether or not a particular IPP server offers "secure"
>> connections. Throughout the IPP model document, numerous
>> assumptions are made with regards to our usage of the "http:" URL
>> to reference IPP objects, chief among these assumptions is that
>> IPP clients treat URL syntax beyond the "host" part of an HTTP URL
>> as opaque.
>>
>> The IPP working group feels that any specification for security
>> parameters within URL syntax should be a "standard" solution and not
>> specifically a "one-off" or one-time only solution for IPP.
>> The effort required to put together a group or effort to accomplish
>> this is out-of-scope for our current charter.
>
>I agree that there is a need to be able to specify the security
>technology which is to be used, especially because there is currently
>no effective way for client and server to negotiate security technology.
>The emerging consensus for indicating authentication technology in a
>URL is to use an AUTH= parameter. However, as far as I can tell,
>this parameter has not been extended to specify uses of TLS.
>
>However, a separate URL type such as "https" is also insufficient for
>IPP's purposes. SSL was designed to authenticate servers to clients,
>not the other way around, and this heritage still shows in TLS.
>The TLS protocol does not have any way for a server to inform a
>client about which certificate authorities it trusts. Unless all
>IPP servers are going to trust the same certificate authority
>(highly unlikely), an IPP client that talks to different servers will
>need multiple key certificates (up to one for each IPP server it
>wants to talk to), and therefore the client either needs to know which
>certificate to send to each server, or it needs to know which CAs
>the server supports.
I assumed that the client and/or server would use the CA that issued
the certicate in the first place. I believe this information is a part of the
certificate itself.
>
>If some sort of prior, out-of-band, authorization is used to establish
>an association between an IPP client and an IPP server, this step
>will need to return credentials (perhaps an X.509 certificate, perhaps
>a password for use with digest authentication) that the client can
>use when authenticating itself to that server. In this case, no extra
>parameters are needed for the printer URL - rather, the client will
>internally maintain lists of authentication credentials indexed by the
>printer name or URL. The authentication method to be used can be
>considered part of those credentials.
>
>If it's desired to make IPP work without prior authorization
>(and assuming the server requires authentication at all), the
>client is still going to need to know what authentication method to
>use and which CAs the server supports. This is more information than
>can be conveyed in one bit (the difference between using "http"
>and "https").
The authentication method is negotiated when the client sends its
"preferred" list of auth/privacy methods to use during TLS startup. It is
assumed
that for "server-initiated" authentication, that pre-configuration of the
server's
idea of "who" is authorized to use the resource will be done so the
credentials
of the client can be "checked".
>
>> 2. There is no straightforward way to configure HTTP client proxy
>> capability for "proxying" IPP. Currently, there are specific proxy
>> configuration options for HTTP clients, such as FTP, GOPHER, HTTP,
>> WAIS, etc. There is no option for proxying "ipp:" URLs and this
>> deficiency could lead to confusion for the end user. Also, to correctly
>> configure a proxy service for IPP, the user will have to "know"
>> that IPP actually uses HTTP, and that for IPP proxy service the user
>> must configure an HTTP proxy.
>
>I don't understand why this is a problem, because existing web clients
>can't usefully talk to IPP servers anyway. They can't generate
>application/ipp requests nor can they parse application/ipp responses.
>So naturally they don't have configuration options to talk to IPP proxies
>either.
>
>As for the potential for end-user confusion: there's far greater
>potential for end user confusion if printers are named with http: URLs.
>
>I don't think the configuration management issues for proxies are
>that difficult to deal with. The IPP configuration can simply have
>a box like:
>
> ------------------------------------------------------
> [ ] make direct connections to an IPP server
> [x] tunnel outgong IPP requests through an HTTP proxy.
>
> proxy host name: [foo.bar.com]
> proxy port number: [8080]
> ------------------------------------------------------
>
>This isn't any worse than for any other protocol.
>
>These are nothing in comparison to the configuration management issues
>for security. How is an IPP client is going to be able to authenticate
>itself to arbitrary IPP servers around the world? If it uses TLS,
>it's potentially going to need to have a variety of key certificates
>on hand (each signed by a different CA), and know which CAs and
>certificate types are recognized by each server, so that it knows
>which certificates to send to which servers.
IPP clients will "not" arbitrarily authenticate itself to IPP servers
around the
world. TLS-enabled IPP servers will be pre-configured with ACLs or some
such to allow
specifically authorized clients to access the resource. Typically, IPP
servers that
arbitrarily open up their resources to any client around the world will be
preconfigured
to allow this type of "anonymous" access, much as their publicly accessible
fax
machines or web servers.
>
>
>> 3. Similar to the end-user configuration problem in #2 above, there is
>> currently no proxy configuration option for IPP proxy in existing
>> proxy server software. IPP will be a "special case" wherein the
>> administrator will have to know the special relationship between
>> IPP URLs and HTTP URLs.
>
>I don't see why this is a problem with the IPP proposal. The IPP
>proposal is to use an http: URL with an explicit port number, so
>that it will be compatible with http proxies.
>
>
>> 4. Future use of the "ipp" scheme is compromised by using the new "ipp"
>> scheme in the translated form implied by the proposed "ipp:" scheme.
>> The IPP working group would like to reserve use of the "ipp" scheme
>> for a pure IPP client/server protocol implementation in the future
>> (one that does not require utilization of an existing HTTP
>> infrastructure). In this environment, it seems appropriate to attach
>> the "ipp" URL to this future protocol, rather than the initial IPP
>> protocol that is just carried in a MIME type within HTTP.
>>
>> For example, in a future implementation of an IPP scheme that does
>> not utilize HTTP, existing IPP clients would still attempt to
>> translate the "ipp:" scheme into an "http:" scheme, and would do so
>> incorrectly, since the future "ipp:" scheme protocol might not use
>> HTTP as a transport.
>
>Anytime a new URI scheme name is defined, it is "compromised" against
>some future use of the scheme name with a different protocol. That's
>not a real problem; we could always define "ipp2" or some other name
>for the new protocol. Chances are we'd want to do that anyway;
>if there were two versions of IPP it would be confusing to use "http"
>to talk to IPP version 1 and "ipp" to talk to IPP version 2 servers.
>
>If what you're saying is that HTTP was a Bad Idea and you want to
>do something different in the future, that implies that this protocol
>is not yet suitable for standardization. If a future version of IPP
>would not make use of the "HTTP infrastructure", then there is no
>reason *not* to use "ipp:" for the current protocol -- since the only
>problems with the use of "ipp:" are the lack of support in the
>HTTP infrastructure. Might as well cross this bridge now.
>
>My opinion is that HTTP is a sub-optimal but sufficient transport
>for IPP, and that it is better to settle on the current version of
>IPP and make it work with the ipp: URL now, than to try to do it later.
>
>By the time there is a completely new printing protocol, it is likely that
>there will be a standard URI resolution mechanism - which would allow
>a client to look up an ipp: URL and find out which printing protocols
>the server supports, before opening up a connection to the server.
>This would allow a smooth transition from IPP 1.0 to the new protocol,
>while using the same URLs.
>
>
>> 5. The proposal introduces "compound" spoofing by using an "ipp:" scheme
>> and transparently translating it to an "http:" scheme An initial
>> concern was the fact that there was no way to tell that IPP was
>> actually being used by looking at an HTTP URL. However, publishing
>> and using only IPP URLs to the user and administrator community might
>> hide the fact that IPP is actually using HTTP.
>
>This is not a problem. IPP's use of HTTP is an implementation artifact,
>not something that users need to be concerned with. Yes, users might
>end up needing to know that they can tunnel IPP over an HTTP proxy.
>But this is easily communicated through user interfaces such as that
>above. And if this technique is approved, it is likely to be regarded
>as a convenience.
>
>(Some folks on the IAB and IESG are still not convinced that IPP should
>be able to tunnel over existing proxies; the counter argument is that
>IPP is going to need proxies anyway, so you might as well use one that
>already exists.)
>
>It's a bit misleading to call this "compound" spoofing, since there
>is only one layer of "spoofing" going on.
>
>
>> 6. Compound schemes is a new idea and not well understood in its'
>> ramifications. In the current IANA registry for URL schemes, there
>> are no examples that indicate that scheme "translation" to another
>> scheme is required.
>
>IPP is the first group to try to layer something on top of HTTP.
>So naturally there are no examples for how to do this. That's
>what comes with breaking new ground.
>
>Note that the translation is only required to talk to HTTP proxies.
>The general case is that the IPP client talks directly to the IPP
>server, and there's no URI translation going on at all.
Your previous comments that say something like "IPP clients will only use
HTTP URLs when speaking to HTTP proxies" eliminates us from fielding IPP
as CGI or NSAPI/ISAPI extensions to generic HTTP 1.1 web servers. These
generic
web servers will not understand IPP URLs either, and this case of generic
web server extension
could make up a significant set of initial releases of IPP.
>
>
>> 7. All applications that include URI/URL recognition features will have
>> to be updated to include support for the new "ipp:" URL.
>
>The applications have to be updated anyway. There are lots of new URI
>types being defined; any generic URI parsing application that can only
>handle specific URL types is already broken. And any application that
>is actually going to make use of ipp: URLs (as opposed to just parsing
>them), is going to have to be updated to generate application/ipp
>requests, parse application/ipp results, and otherwise provide a useful
>user interface to printers.
>
>
>> 8. Existing network infrastructure tools and utilities would need to
>> be modified in order to understand the "special" relationship
>> between IPP and HTTP URLs.
>>
>> The working group considers IPP printing an "HTTP application", and
>> therefore the usage of an "ipp:" URL scheme must maintain a special
>> relationship with "http:" URLs. The definition of such a "compound"
>> URL scheme, wherein an "ipp:" scheme is layered or translated to an
>> "http:" scheme, is somewhat unusual, and the impact of such a definition
>> on the protocol design and deployment is not generally well understood.
>
>The IESG considers IPP separate and distinct from normal web service,
>requiring a separate URI type. The layering of IPP on top of HTTP,
>while somewhat unusual, does not change this.
>
>> This analysis document has identified a partial list of issues regarding
>> the integration of the new "ipp:" scheme. It is anticipated that other
>> unforeseen issues exist, since this technique has not been prototyped.
>>
>> If the usage model described herein were adopted, these issues raised in
>> this analysis pose a significant negative impact on the implementation
>> and deployment of current IPP specifications, as well as potential
>> interoperability with future revisions of the protocol.
>
>This negative impact has to be weighed against the considerable negative
>impact associated with use of the http: scheme.
>
>
>
>Summary of my position:
>
>1. I agree that more work needs to be done to specify security level
>in IPP URLs. The "https" scheme (which wouldn't be accepted anyway)
>is insufficient, and use of the AUTH= parameter with TLS is not
>sufficiently well defined for any other URL scheme, to allow IPP
>to cut-and-paste another specification.
>
>Note that these are as much limitations of HTTP and TLS (to fail to
>provide adequate negotiation of security parameters) as of URLs.
>If there were a better way for client and server to negotiate security,
>this would lessen the need to expose this information in the URL.
>
>Note that this is much a limitation of HTTP and TLS (to fail to
>provide adequate negotiation) as of URLs.
>
>
>2. I believe the "negative impact" claimed by the IPP group is
>exaggerated, and does not consider the negative impact to the
>community of overloading the http: URI scheme.
>
>I respect the IPP group's concern that translation of IPP URLs
>while tunneling over HTTP proxies is untried and may cause operational
>problems. However, the IPP group is ignoring IESG concerns about
>operational problems that might be caused by reusing HTTP proxies
>in the first place to circumvent firewall policy, or the confusion
>resulting from users' inability to distinguish printer URLs from
>http: URLs.
>
>If IPP's use of HTTP proxies causes too many problems, it may be
>necessary to reconsider using HTTP proxies - or to allow people
>to use them, but warn that this might not always work. Sooner
>or later the proxies will support IPP. Of course it's nice if
>proxies support a new protocol immediately, but if they don't -
>this is no more of a barrier than any other new protocol has to face.
There is no problem with our current version and HTTP proxies. Its the
introduction of an unsupported URL scheme that has generated
concerns about breaking the infrastructure. We have layered where
appropriate, and have taken special care not to "break" the infrastructure.
We have a default port number that eliminates the majority of concern
over which protocol is in use, so we think the price to paid by having
to go out and set up all of this other support/work with other groups is
not going to
give us the benefit. Its basically alot of work and prototyping that has to
be done for not much benefit.
I'm concerned that if we did work on a "standardized" URL, that it would
"still" be
a "one-off" solution only used by IPP, since the majority of internet
protocols I am seeing
working on security (IMAP/POP/FTP/SMTP/LDAP, etc) are working on SASL
profiles for accomplishing this functionality. Which would make all of this
work
even less of a benefit.
>
>
>My proposal:
>
>The IPP documents will not be approved as a Proposed Standard until
>they are fixed to use ipp: URLs instead of http: URLs.
>
>With an eye toward making them acceptable to IESG while addressing
>the IPP group's concerns:
>
>- I will recruit a team of experts from the HTTP working group
>and ask them to quickly review the ipp: scheme proposal for potential
>interoperability problems with proxies.
>
>- I will recruit experts from the web and TLS communities to design
>appropriate URL parameters for use with TLS, which can be shared
>by other URL schemes besides ipp:.
>
>The IPP documents have been submitted for IESG ballot, and may be
>on IESG's agenda for discussion as early as July 16th. I would
>therefore like a decision from IPP by July 15th as to whether
>the IPP working group is willing to pursue this course of action.
If we subscribe to your schedule I think its only fair that we get a
schedule back from you for completion of this work, provided we agree
to it.
Thanks
Randy
>
>Note that there may still be other IESG concerns with this protocol,
>particularly on security. We won't know about those until the IESG
>finishes its ballot.
>
>Keith
>