IPP Mail Archive: Re: IPP> Re: Printer Driver Extension

IPP Mail Archive: Re: IPP> Re: Printer Driver Extension

Re: IPP> Re: Printer Driver Extension

From: Paul Moore (pmoore@peerless.com)
Date: Wed May 03 2000 - 19:49:32 EDT

  • Next message: Carl-Uno Manros: "RE: IPP> How to prevent spam in email notifications?"

    The right thing to do is digitally sign the drivers. The more recent versions of
    Windows (2000 and 98SE I think)support this. In the case where the drivers are
    not signed then depending on the settings on the client the driver will be
    rejected or the user will be given the choice about installing it or not.

    But this whole idea of loading executable code from the network is a potentially
    huge hole. On NT4 and for some windows 2000 drivers the driver is kernel mode
    code - the idea of installing stuff with that level of trust from who knows
    where is scary. Digest does not help as it allows the server to trust the client
    - what we need is for the client to trust the server. This means that it must
    use SSL or TLS.

    Michael Sweet <mike@easysw.com> on 05/03/2000 11:57:29 AM

    To: Hugo Parra <HPARRA@novell.com>
    cc: lfarrell@cissc.canon.com, hastings@cp10.es.xerox.com,
          rbergma@hitachi-hkis.com, don@lexmark.com, carl@manros.com,
          Robert.Herriot@pahv.xerox.com, pmoore@auco.com, ipp@pwg.org,
          imcdonald@sharplabs.com, harryl@us.ibm.com, Peter.Zehler@usa.xerox.com
          (bcc: Paul Moore/AUCO/US)

    Subject: IPP> Re: Printer Driver Extension

    Hugo Parra wrote:
    > ...
    > IPP currently requires Digest Authentication. Wouldn't this be
    > sufficient?

    I dunno. Digest can be used to authenticate the transfer of the
    file from the server to the client (e.g. "man in the middle"
    attacks), but it doesn't protect against attacks that originate
    on the server itself. In other words, the IETF may require that
    IPP provides some mechanism for doing third-party authentication
    as well (not necessarily as part of IPP) so that the source (the
    IPP object) can be authenticated.

    Of course, Digest *may* be sufficient for the protocol and that
    may be all we need to worry about, but we need to address all
    security concerns, vulnerabilities, etc. since we're talking about
    executable code...

    > ...
    > A couple of popular systems I'm familiar with download printer
    > drivers from places on the network much more obscure than the
    > printer users intent to print to. I understand that's not a good
    > enough argument to sell the proposal to the IESG. What I'm saying
    > is that there's a real and pressing need for this functionality and
    > if we don't address the need in the standard, people are going to do
    > it proprietarily (is that a word?), guaranteed. So we require
    > Digest Authentication and/or TLS in the spec and let implementors
    > decide if their target market justifies the cost of including the
    > extra security.

    There are two issues - supporting different types of printers and
    drivers, and ensuring some minimum level of security.

    Any IPP extension MUST be capable of supporting multiple platforms;
    all IETF standards are supposed to be platform and vendor neutral.

    > Realize that most users will have already established some level of
    > trust on the printer they intent to download a driver from, as
    > they're willing to submit documents to be printed on that device.

    I don't think trust has anything to do with it, aside from maybe
    trusting that the printer won't jam or something.

    > This trust might be based on the fact that they're using an IPP url
    > off an internal corporate site, or a url off a well-known web site
    > which they might have already validated using SSL or TLS.

    I'd say that most users don't even think about network security
    unless their credit card number is involved...

    > ...
    > Let's fix collections or embrace an alternative solution that keeps
    > things simple. I strongly disagree with those who think we don't
    > need this functionality in IPP. We can't go on kludging specialized
    > encodings each time we run into this problem (a la "tree amigos"
    > attributes).

    I'm not sure that we're on that path - so far we've only encountered
    three situations in which collections might be useful, and the
    current IPP specs and extensions probably cover 95% of all network
    printing needs.

    IMHO collections will only complicate IPP implementations. Current
    implementations can work with a fixed set of data types, with
    reasonably deterministic results. Adding collections makes the
    job of implementing, testing, and validating IPP software harder
    and less deterministic.

    > ...
    > I like the idea of endorsing other Standards work and we should
    > make sure the solution we choose allows the UPDF (and PPD)
    > technology to be used. But as you point out, the UPDF effort is
    > far from complete and we don't have the luxury to wait another
    > year, to be extremely optimistic, before UPDF reaches any type of
    > critical mass presence. We cannot ignore either the enormous
    > wealth of legacy printer drivers.

    I'm still not sure how easy it will be to support "legacy printer
    drivers" with your proposal. Any current format used by PC printer
    drivers (e.g. self-extracting ZIP files, .CAB files, etc.) will
    certainly raise flags in the IETF.

    > ...
    > Windows clients (in al their incarnations) currently make up the
    > bulk of our market. So PPD is definitely not an answer.

    Except that 99% of the IPP-capable printers are PostScript capable...

    --
    ______________________________________________________________________
    Michael Sweet, Easy Software Products                  mike@easysw.com
    Printing Software for UNIX                       http://www.easysw.com
    



    This archive was generated by hypermail 2b29 : Wed May 03 2000 - 19:58:29 EDT