Re: Requiring authentication for all IPP operations with "cloud" Infrastructure printer

"Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email protected]> Fri, 12 Nov 2021 21:01:25 +0000
Newsgroups	gmane.ietf.ipp
Message-ID	<[email protected]>
Hi Mike,

> On Nov 12, 2021, at 11:34 AM, Michael Sweet <[email protected]> wrote:
> 
> Smith,
> 
>> On Nov 12, 2021, at 12:49 PM, Kennedy, Smith (Wireless & IPP Standards) <[email protected]> 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.


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

> 
> ________________________
> Michael Sweet

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp
signature.asc (application/pgp-signature, 833 B)