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

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Fri, 12 Nov 2021 17:49:04 +0000

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

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.

Thoughts?

Smith

/**
    Smith Kennedy
    HP Inc.
*/

> On Nov 11, 2021, at 6:49 PM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> +1 to future discussion in IPP Implementors Guide.
> 
> +1 to near-term discussion in Enterprise Printing Extensions.
> 
> +1 to also saying something in IPP 2.x 4th Edition.
> 
> I suggest we should take this topic to the IPP WG mailing list.
> 
> I do agree that it's not desirable that IPP Infrastructure Printers should
> accept anything except Get-Printers w/out TLS security.
> 
> Cheers,
> - Ira
> 
> Ira McDonald (Musician / Software Architect)
> Chair - SAE Trust Anchors and Authentication TF
> Co-Chair - TCG Trusted Mobility Solutions WG
> Co-Chair - TCG Metadata Access Protocol SG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: [email-masked] <mailto:[email-masked]>
> (permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
> 
> On Wed, Nov 10, 2021 at 11:08 PM Kennedy, Smith (Wireless & IPP Standards) <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On Nov 10, 2021, at 6:10 PM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Smith,
> >
> > It isn't so much explicitly disallowing it, it is just that Get-Printer-Attributes is the only operation in STD92 that doesn't talk about access rights and historically no implementation has ever required authentication for it.  As a result, no client supports authentication when querying printer status/capabilities with Get-Printer-Attributes...
> 
> Wow, I am surprised that I didn't have this committed to memory. 😞 That makes it pretty awkward to cite from a normative / testing point of view. I really think somewhere needs to overtly state this. Maybe IPP/2.0 Fourth Edition? I also think this should be discussed more clearly in the IPP IG and maybe in Enterprise Printing Extensions which now hosts the definition of Get-User-Printer-Attributes.
> 
> >
> >
> >> On Nov 10, 2021, at 6:17 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> I was being asked which specific clause in a PWG or IETF IPP spec actually made that assertion. I was unable to locate it. 😞  Can you point out the clause in one of our specs that specifically disallows authentication with Get-Printer-Attributes?
> >>
> >> For an infrastructure printer, it really doesn’t seem unreasonable for the Printer to require authentication for all IPP operations, including Get-Printer-Attributes. I suppose that could cause problems with legacy clients. But that seems to leave the door open to abuse or at least misunderstanding by “security researchers”.
> 
> Any comments or thoughts on this? I wonder if we ought to have 5100.18 v1.1 say that the unauthenticated Get-Printer-Attributes should limit the attributes it provides.
> 
> >>
> >> Cheers,
> >> Smith
> >> ---
> >> Smith Kennedy
> >> [email-masked] <mailto:[email-masked]>
> >>
> >>
> >>> On Nov 10, 2021, at 3:42 PM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
> >>>
> >>> Smith,
> >>>
> >>> The "rules" are the same for Cloud vs. local - all operations *except* Get-Printer-Attributes/Get-System-Attributes can require authentication. The Get operations are exempt because they are the only way to discover what the authentication requirements are... :)
> >>>
> >>>
> >>>> On Nov 10, 2021, at 4:57 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>
> >>>> Hi there,
> >>>>
> >>>> If you have a "cloud" printer, is it "OK" to have the cloud Printer (Infrastructure Printer) require authentication for ALL IPP operations?
> >>>>
> >>>> I'm trolling through 8011 and 5100.18 to see if I can find language on the subject but if either of you know that would be helpful.
> >>>>
> >>>> Smith
> >>>>
> >>>> /**
> >>>> Smith Kennedy
> >>>> HP Inc.
> >>>> */
> >>>>
> >>>
> >>> ________________________
> >>> Michael Sweet
> >>>
> >>>
> >>>
> >
> > ________________________
> > Michael Sweet
> >
> >
> >
> 

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

---

From: Michael Sweet via ipp <[email-masked]>
Date: Fri, 12 Nov 2021 13:34:56 -0500

Smith,

> On Nov 12, 2021, at 12:49 PM, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]> wrote:
> 
> Hi Ira,
> 
> 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.
3. All other operations enforce the legal access permissions.

> 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 eithe…

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.

________________________
Michael Sweet

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Fri, 12 Nov 2021 21:01:25 +0000

Hi Mike,

> On Nov 12, 2021, at 11:34 AM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 

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.

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

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

---

From: Michael Sweet via ipp <[email-masked]>
Date: Fri, 12 Nov 2021 21:22:19 -0500

Smith,
On Nov 12, 2021, 4:01 PM -0500, Kennedy, Smith (Wireless & IPP Standards) <[email-masked]>, wrote:
	Hi Mike,

Smith,

Hi Ira,

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…

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? :)