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 <blueroofmusic at gmail.com> 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: blueroofmusic at gmail.com <mailto:blueroofmusic at gmail.com>
> (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) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
>>> > On Nov 10, 2021, at 6:10 PM, Michael Sweet <msweet at msweet.org <mailto:msweet at msweet.org>> 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) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> 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
> >> smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>
> >>
> >>
> >>> On Nov 10, 2021, at 3:42 PM, Michael Sweet <msweet at msweet.org <mailto:msweet at msweet.org>> 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) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> 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
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20211112/5ae73c6d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20211112/5ae73c6d/attachment.sig>