Subject: [IPP] implementor's guide recommendation for Printer with IPPS enabled but conventional IPP disabled should respond

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Fri, 24 Jan 2014 05:24:45 +0000

Greetings,

I came across a scenario that I think needs characterization in the implementor’s guide.  The scenario is this: a Printer has IPPS enabled but conventional IPP disabled, and it receives a “conventional” HTTP connection from a client.  How should the printer respond?

I am thinking that, if the Client sends an HTTP/1.1 Expect header, then that is covered in the guide already (wd-ippig20-20140108.pdf section 8.1): the Printer responds with an HTTP 426 Upgrade to upgrade the connection.  But if the Client does not use the HTTP/1.1 Expect header, I’m not sure what we should recommend the printer to do.

I’m also not sure whether this is really a legitimate scenario.  If there are some operations that should never require TLS or any form of authentication (the two are related but not the same) then perhaps the Client will not be upgraded right away, and then will not be expecting a later upgrade, and may leak information “accidentally”.  For instance, if the Client does a Get-Printer-Attributes operation request that includes the HTTP/1.1 Expect header, it may get back a HTTP 100 Continue.  If it switches to a different operation, like Validate-Job or Create-Job, I think it should once again include the HTTP/1.1 Expect header.  This specific recommendation detail is currently not covered in wd-ippig20-20140108.pdf section 8.

Am I off in the weeds?  This seems to me like a legitimate concern.  If I was a new Client implementor, I’d want to know at what points in the algorithms we cover in section 4 I should be sending an HTTP/1.1 Expect, what points I should be expecting a redirect before sending potentially sensitive information on the wire, etc.

Thanks for any thoughts and feedback!  I’ll update section 8.1 to try to cover this in my next revision (hopefully posted tomorrow).

Smith

/**
    Smith Kennedy
    Hewlett-Packard Co.
*/

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Fri, 24 Jan 2014 11:31:02 -0500

Smith,

> I came across a scenario that I think needs characterization in the implementor’s guide.  The scenario is this: a Printer has IPPS enabled but conventional IPP disabled, and it receives a “conventi…

A HTTP sever can return a 426 status with or without the Expect: 100-continue header in the request.  This is already covered in RFC 2817.

Clients that do not support TLS Upgrade will simply treat the 426 status as a hard error.

> ...

Yes, the Client should always send Expect: 100-continue unless it knows the Printer does not support it (which is buggy behavior anyways, but ...)

> Am I off in the weeds?  This seems to me like a legitimate concern.  If I was a new Client implementor, I’d want to know at what points in the algorithms we cover in section 4 I should be sending a…

It goes beyond TLS - some IPP operations may require authentication, others may not depending on the policy configured in the Printer.  So Clients should always include the Expect header unless they know the Printer does not support it, and that allows the correct things to happen without leaking information the Server wants to be confidential based on its configuration.

Clients, of course, should probably always support TLS and always include the Upgrade header indicating their willingness to upgrade to TLS, at a minimum.  And there should be a preference for IPPS when the Printer supports both IPP and IPPS (or at least a way to select that, given the overhead of TLS...)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Fri, 24 Jan 2014 19:54:20 +0000

Thanks for your reply Mike!

To try to be more concise, should IPPIGv2 include Printer recommendations to prevent or stop an imprudent Client from sending  “sensitive information” in the clear before the Printer can respond with a 426 Upgrade?

I do understand that HTTP/1.1 Expect isn’t required for an upgrade.  If the Client included the HTTP/1.1 Expect header, the Printer could reply early with a 426 before the sensitive information hit the wire.

> It goes beyond TLS - some IPP operations may require authentication, others may not depending on the policy configured in the Printer.  So Clients should always include the Expect header unless the…

Right! I was thinking about that as well this morning.  Should there be yet another attribute like “ipp-operations-requiring-tls”?  (Or if we really want to shoot down the rabbit hole, “ipp-operations-security-policy-col”? Gack…)  Is there anything like this in the SM?

Smith

---

From: Michael Sweet <[email-masked]>
Date: Fri, 24 Jan 2014 15:07:42 -0500

Smith,

> To try to be more concise, should IPPIGv2 include Printer recommendations to prevent or stop an imprudent Client from sending  “sensitive information” in the clear before the Printer can respond wi…

There isn't much you can do beside advertise only IPPS with any discovery protocol or directory service.

> I do understand that HTTP/1.1 Expect isn’t required for an upgrade.  If the Client included the HTTP/1.1 Expect header, the Printer could reply early with a 426 before the sensitive information hit…

Exactly.  I think we need to document both the best practices and recovery strategies for common issues in the IIG2.

> Right! I was thinking about that as well this morning.  Should there be yet another attribute like “ipp-operations-requiring-tls”?  (Or if we really want to shoot down the rabbit hole, “ipp-operati…

Nothing yet, but the IDS workgroup has, as part of its charter, a mandate to define policy mechanisms.  This may lead to a corresponding IPP binding spec in the future.

But regardless, IPP and HTTP already provide the necessary infrastructure for a Printer to enforce and a Client to respond to policy requirements for authentication, access control, and confidentiality.  That is enough for the IIG2...