Smith,
On Nov 12, 2021, 4:01 PM -0500, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com>, wrote:
Hi Mike,
On Nov 12, 2021, at 11:34 AM, Michael Sweet <msweet at msweet.org> wrote:
Smith,
On Nov 12, 2021, at 12:49 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com> wrote:
Hi Ira,
As you suggested, I've added the IPP Workgroup reflector to the list of recipients to bring this sidebar discussion into the forum without having to start from scratch.
I do agree that it's not desirable that IPP Infrastructure Printers should
accept anything except Get-Printers w/out TLS security.
If an Infrastructure Printer object is supposed to be available on the Internet but for "private use only", how does that work given the legacy Get-Printer-Attributes use precedent?
OK, some (hopefully obvious) observations:
0. We need to separate the notion of legal access and protocol access to a service.
1. A service that accepts connections over the Internet is, by definition, publicly accessible at the protocol level.
2. Get-Printer-Attributes (and Get-System-Attributes) allow a Client to determine the *legal* access permissions.
So protocol access == YES and legal access == YES for Get-Printer-Attributes and Get-System-Attributes.
3. All other operations enforce the legal access permissions.
So protocol access == YES but legal access == MAYBE (may require authentication).
If Get-Printer-Attributes and Get-System-Attributes are always legally accessible, then it seems to me that all of the Printer's Printer Description attributes and/or System's System Description attributes have to be "safe" i.e. free of PII and not confidential. And we need to clearly assert that somewhere so that we can point to that assertion.
No, we need to document that attributes can/might contain PII and it is up to the administrator to restrict network access and/or configure the attributes to remove any PII. We don’t make assertions like this in PWG specs, we merely identify potential issues.
Honestly, the Internet-accessible address and URI of a service is PII enough to uniquely identify a particular printer/service. The administrator has control over the contact info which will typically be blank/empty by default…
What should the response be from the "System Service" or other process actually hosting the IPP Printer object? HTTP 404? Or an IPP layer equivalent? I'm not sure we ever considered this use case in 5100.18.
HTTP 200 OK with the full set of attributes and values.
At the very least, we need to have a statement / paper prepared that provides guidance to Infrastructure Printer implementors to the critique that a Get-Printer-Attributes does not constitute either a security or a privacy risk. If each cloud / Infrastructure Printer hosting provider does something different, that makes it very difficult for client implementations to support in any consistent way.
It makes sense to add a discussion of Get-Printer-Attributes to the IPP/2.x update and log an issue against PWG 5100.22 for Get-System-Attributes. We might also include references to this in 5100.18.
I think from the point of view of a vendor or service provider that owns or manages a publicly accessible IPP Printer object, I would want a clear and confidently stated statement that this is by design and doesn't represent an attack surface so long as the set of Printer Description / Printer Status attributes are "safe", so that if we get scrutinized by someone claiming a security concern, we can reference the PWG clauses and say "works as expected”.
The attributes are (per STD92) there to describe the state, capabilities, and configuration of the printer/system object so that a Client is able to use it. I see no reason to make *any* further statements concerning their necessity or that they are “as designed”.
So while it *is* appropriate to note potential security/privacy considerations, it isn’t appropriate for us to make any legal claims or restrict usage over the Internet. After all, the I in IPP is Internet, right? :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20211112/0f13b59f/attachment.html>