Subject: IPP> Re: IPP Scheme

From: Keith Moore <[email-masked]> (by way of Carl-Uno Manros <[email-masked]>)
Date: Fri, 10 Jul 1998 19:23:45 -0700

IPP WG members,

Please look over Keith's reply to each of the concerns that were raised in 
the Monterey meeting earlier this week. I would like to have your quick 
feedback on Keith's latests suggestions. Does his proposed resolutions
in combination with the offer to get some real expert help (which we
have been loooking for for a long time), change your attitude towards 
the IPP scheme proposal? Keith would like to get our reaction by 
July 15th. I will be on the road on July 13 and 14 and will
probably only be able to check mail early and late in the day.

Carl-Uno

> -------------------------------------------------------------------
> 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.

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").

> 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.

> 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.

> 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.

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.

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

---

From: Randy Turner <[email-masked]>
Date: Sat, 11 Jul 1998 21:18:31 -0700

Some comments on Keith's responses below.

Randy

>certificate to send to each server, or it needs to know which CAs

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.

>can be conveyed in one bit (the difference between using "http" 

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". 

>that difficult to deal with.  The IPP configuration can simply have 

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.

>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.

>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. 

>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

---

From: Keith Moore <[email-masked]>
Date: Sun, 12 Jul 1998 19:39:29 -0400

> the certicate in the first place. I believe this information is a part of the

No, that's not the issue.  Yes, the CA is part of the certificate.
The client may need several certificates to authenticate itself
to each of several different servers,  because each client certificate
is signed by only one CA, and not all servers trust the same CA.
The client has no knowledge of which certificate to use, and TLS 
doesn't give it a way find out which CAs the server trusts.  
So this has to be configured into the client on a per-printer basis -
either explicitly or as part of the URL.

> "preferred" list of auth/privacy methods to use during TLS startup. 

Only if it uses TLS.  How does the client find out whether to use TLS 
or digest or both?  (it might use TLS for privacy, and digest for
authentication)

> 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. 

Yes, but how does this work for the client who wants to print
on the printer at Kinko's?  (whether nearby or across the world)
Presumably, the user's going to have to establish a billing account, 
and when he does that he'll get a certificate back from Kinko's that 
he can use to authenticate himself to Kinko's printer.  (my guess
is that it's a lot easier for Kinko's to issue a certificate
that says "this is Kinko's user #23434" than for Kinko's to 
decide whether to accept some certificate that the user already
has, signed by some random CA, that says "this is Keith Moore".)

(note that there's a big gap in defining "ACLs or some such")

> 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.

This is a reasonable concern.  I'm thinking that it's not such a problem
if http: URLs are always used at the HTTP layer - as long as they're only
used at the HTTP layer.  I might be able to convince IESG of this.

> appropriate, and have taken special care not to "break" the infrastructure.

With due respect, the IESG disagrees.  The layering of a new protocol
over HTTP, and the proposed reuse of http: URLs, has generated concerns
about breaking widely-held assumptions - specifically, firewall policies
and assumptions about what http: means and how it is used.

> "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. 

I don't think this would be a one-off.  There's a lot of interest in
using TLS for most of these protocols, and the mechanism for negotiating
TLS (typically a STARTTLS command) sort of sits alongside of SASL.
So I think we're going to be needing URLS that can specify use of
either SASL methods, or TLS, or both, for several different protocols.

I've already been asked by someone else from outside of the IPP group,
to hold a discussion at the next IETF meeting, about a reusable 
mechanism for specifying various kinds of security in URLs.

> schedule back from you for completion of this work, provided we agree

Well, if I can get IESG to agree to let IPP use http: in HTTP
protocol elements, then we don't need the first team of experts.

As for the second, I would need to talk to security experts
before I could even get a time estimate.  But it might be
that this doesn't have to be critical path for IPP going to
proposed.  I'll ask the security ADs what they think.

Keith

---

From: "Carl Kugler" <[email-masked]>
Date: 13 Jul 1998 15:53:55 -0000

> Some comments on Keith's responses below.
...
> could make up a significant set of initial releases of IPP.

I don't agree that using IPP URLs prevents fielding IPP as CGI or NSAPI/ISAPI extensions to generic HTTP 1.1 web servers.  Isn't it true that the web server doesn't need to understand IPP URLs, since they never appear on the wire (outside of the application/ipp body)?  The one exceptional case is that in which the client is talking to a proxy server and must transmit the absolute URL in the Request-URI.

-----
Original Message: http://www.findmail.com/list/ipp/?start=4078
Start a FREE email list at http://www.FindMail.com/

---

From: Randy Turner <[email-masked]>
Date: Mon, 13 Jul 1998 09:07:32 -0700

Keith was suggesting that, in the absence of a proxy server, that "ipp:"
URLs would be used in both HTTP headers and in the application/ipp body
part. I believe this would definitely impact generic HTTP 1.1 web servers.

Randy

At 03:53 PM 7/13/98 +0000, Carl Kugler wrote:
>I don't agree that using IPP URLs prevents fielding IPP as CGI or
NSAPI/ISAPI extensions to generic HTTP 1.1 web servers.  Isn't it true that
the web server doesn't need to understand IPP URLs, since they never appear
on the wire (outside of the application/ipp body)?  The one exceptional
case is that in which the client is talking to a proxy server and must
transmit the absolute URL in the Request-URI.

---

From: Keith Moore <[email-masked]>
Date: Mon, 13 Jul 1998 19:57:53 -0400

> part. I believe this would definitely impact generic HTTP 1.1 web servers.

yes, and I agree.  which is why I proposed that the http: form of the
URL could always be used at the HTTP layer.

Keith