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

"Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email protected]>
Newsgroups gmane.ietf.ipp
Message-ID <[email protected]>
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 protected]> 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 protected] <mailto:[email protected]>
> (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 protected] <mailto:[email protected]>> wrote:
> 
> 
> > On Nov 10, 2021, at 6:10 PM, Michael Sweet <[email protected] <mailto:[email protected]>> 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 protected] <mailto:[email protected]>> 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 protected] <mailto:[email protected]>
> >>
> >>
> >>> On Nov 10, 2021, at 3:42 PM, Michael Sweet <[email protected] <mailto:[email protected]>> 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 protected] <mailto:[email protected]>> 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 protected]
https://www.pwg.org/mailman/listinfo/ipp
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEX4TM/E2Pr7lTZzy2qskbKLDW1N0FAmGOqQoACgkQqskbKLDW
1N3VaxAAjhDMUat0upBTNAlmZGHEa2PXE0u6f8cmVRgt1RnVu9QdhDX80WENSywU
1GhGwxGBiXsvP+GNJsps8jM7Rz48JEKlmoiqSYBPwTZxCGVENvdBgO7UeyJrNIIh
+mgwl+ksYk5iHfWJumifTRsiWuCZ+1m1XEU+3bzfkXbbtQjv+EIrU+mIQ6uXMUyB
qN6qWeFoEWixU28XZ1upoa/4GqWSOliUQin/t6f/cZlbPw+YASOPANV26gWTreeD
zscxoQK/MddTKc4QED9KftNB9RUHnnfJSnISMYXxGIKTSRh0Wih5uVPvOKztcuLw
QuKYnoQy82fG4vjaE3xuffbQRMyr7VBAm3PgiDlzE5mhrc92bCcJA02tW3oNyCVR
LVvwU+9L2ot9pq7eC82T9Z1G5qqVm4fqCKQzr16jsyKZag/dh+k90HciUr4EqaN6
eeJbSMFPvdLjN5ULyAeErgP9p1eZdhxdWiKkKfzSLAEhQ1QLgmyL6MzgVFcy8ZiA
NkQUusEC6G210XoCdg1qt/nnaBZtQBu3+gqULir+6GCqm1tYUrgIObIEh/ScGnIs
ELpVjCH4uSCDY0RNak/4CURpEgIKbCAzlBpIq9Wx/B/j/S/9gaXZeGdxfq3ztF7c
TSwKDcGRknATeI961s6NXvYTdwJcSqSgzMLiBrdbcxpvrcYZhMc=
=rO5N
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.