Re: [IPP] Requiring authentication for all IPP operations with "cloud" Infrastructure printer
Michael Sweet via ipp <ipp@pwg.org> Fri, 12 November 2021 18:35 UTC
Return-Path: <ipp-bounces@pwg.org>
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 11BC73A1059
for <ietfarch-ipp-archive@ietfa.amsl.com>; Fri, 12 Nov 2021 10:35:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MAILING_LIST_MULTI=-1,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001]
autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key)
header.d=pwg.org header.b=tsKNJ6z5; dkim=pass (1024-bit key)
header.d=pwg.org header.b=DLKEvpam; dkim=fail (1024-bit key)
reason="fail (message has been altered)" header.d=msweet.org
header.b=sB1jxQfC
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fP_e1ozAcyfp for <ietfarch-ipp-archive@ietfa.amsl.com>;
Fri, 12 Nov 2021 10:35:04 -0800 (PST)
Received: from mail.pwg.org (mail.pwg.org [50.116.7.199])
by ietfa.amsl.com (Postfix) with ESMTP id B7DF13A1056
for <ipp-archive2@ietf.org>; Fri, 12 Nov 2021 10:35:04 -0800 (PST)
Received: by mail.pwg.org (Postfix, from userid 1002)
id ECFA3F085; Fri, 12 Nov 2021 18:35:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.pwg.org ECFA3F085
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pwg.org; s=default;
t=1636742103; bh=0fmTPlDsZ2FXE6BwHKWjALlCY1mEl0Yg20S4VAVC82I=;
h=In-Reply-To:Date:References:To:Cc:Subject:List-Id:
List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
From:Reply-To:From;
b=tsKNJ6z5C/Q5ckScNcaqfDFoNcITS65WMPDTSD0kDH8ix5/9n0cW/rQwaMwUmS8W9
bbV2WgZ6wyDaOfvEgcxOLhX4wwEEk5kH9si18jjnbu9c5tpXgsTxOQZ6OOLhEFhBat
5rFs4N5yIhmbuMgxkyAGfhN2SyPT0L+xPDVOgUvs=
Received: from mail.pwg.org (localhost [IPv6:::1])
by mail.pwg.org (Postfix) with ESMTP id A9AC3F06E;
Fri, 12 Nov 2021 18:35:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.pwg.org A9AC3F06E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pwg.org; s=default;
t=1636742100; bh=0fmTPlDsZ2FXE6BwHKWjALlCY1mEl0Yg20S4VAVC82I=;
h=In-Reply-To:Date:References:To:Cc:Subject:List-Id:
List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
From:Reply-To:From;
b=DLKEvpamm6IrLV26n74wC/SN6eN8GDP3PiOGN0IsqRjpMhVbzWoY/3p0I2IhoSzY0
kKc6kB9dVyK4hSMfDmNEWgalymYH5mCYbhvE+J5Eh3lVBJfm1wtBnDCBMS1azSPM7e
0xbhsxlckQ/GEtzz9aFx5mbTIDFvLP2X2jN2BnXE=
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: by mail.pwg.org (Postfix, from userid 1002)
id 2B375F080; Fri, 12 Nov 2021 18:34:59 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.pwg.org 2B375F080
Authentication-Results: mail.pwg.org;
dkim=pass (1024-bit key) header.d=msweet.org header.i=@msweet.org
header.b="sB1jxQfC"
Received: from mail.msweet.org (mail.msweet.org [173.255.209.91])
by mail.pwg.org (Postfix) with ESMTP id B6E5BA78
for <ipp@pwg.org>; Fri, 12 Nov 2021 18:34:58 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.pwg.org B6E5BA78
Received: from smtpclient.apple (cbl-66-186-76-47.vianet.ca [66.186.76.47])
by mail.msweet.org (Postfix) with ESMTPSA id 8CAC1803B5;
Fri, 12 Nov 2021 18:34:57 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.msweet.org 8CAC1803B5
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=msweet.org;
s=default; t=1636742097;
bh=vwfg1DELbUCp8pll9zvJ4MVxkr91FkGM+BukkcARsaU=;
h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
b=sB1jxQfCQuLMsfgz0QmRBrFlZdIFaA+fKMlbs8vwQ4bygYUabHsZiP4E7m43znGds
k3mapY19z1Ek/Wf+cgZTqibGwz0Llaueo6ASROqs7qlqirBLxGig6xqcyftf0ZhH+Z
0wbFO80vSklYUqXH0LcF+eyFYjXPFQouUIgt9QIY=
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
In-Reply-To: <77D30945-1B08-4954-BA1F-D66CB9A32B2C@hp.com>
Date: Fri, 12 Nov 2021 13:34:56 -0500
Message-Id: <12D1CCDB-B619-49B4-8209-4FABDA20887C@msweet.org>
References: <0446E67E-3B0F-442B-B51E-ED7966C71E82@hp.com>
<C1D8E8B0-614C-41AE-AAA3-23AECA70927E@msweet.org>
<9DDE6032-F733-4540-99C7-D2F5A13766EA@hp.com>
<0AFEFF7B-526F-4DE5-9F5C-2C91ABD717BA@msweet.org>
<BD403A4C-D49F-4203-AC89-D458D598B9FA@hp.com>
<CAN40gSs4OB441bZVYmx4T-VkCRqOiZScnGYHXZB3xkE1vzZMKA@mail.gmail.com>
<77D30945-1B08-4954-BA1F-D66CB9A32B2C@hp.com>
To: "Kennedy, Smith (Wireless & IPP Standards)" <smith.kennedy@hp.com>
X-Mailer: Apple Mail (2.3693.20.0.1.32)
Cc: PWG IPP Workgroup <ipp@pwg.org>
Subject: Re: [IPP] Requiring authentication for all IPP operations with
"cloud" Infrastructure printer
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: ISTO-PWG Internet Printing Protocol workgroup discussion forum
<ipp.pwg.org>
List-Unsubscribe: <https://www.pwg.org/mailman/options/ipp>,
<mailto:ipp-request@pwg.org?subject=unsubscribe>
List-Archive: <http://www.pwg.org/pipermail/ipp/>
List-Post: <mailto:ipp@pwg.org>
List-Help: <mailto:ipp-request@pwg.org?subject=help>
List-Subscribe: <https://www.pwg.org/mailman/listinfo/ipp>,
<mailto:ipp-request@pwg.org?subject=subscribe>
From: Michael Sweet via ipp <ipp@pwg.org>
Reply-To: Michael Sweet <msweet@msweet.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: ipp-bounces@pwg.org
Sender: "ipp" <ipp-bounces@pwg.org>
Smith, > On Nov 12, 2021, at 12:49 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy@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. 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 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. ________________________ Michael Sweet _______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp
- Re: [IPP] Requiring authentication for all IPP op… Kennedy, Smith (Wireless & IPP Standards) via ipp
- Re: [IPP] Requiring authentication for all IPP op… Michael Sweet via ipp
- Re: [IPP] Requiring authentication for all IPP op… Kennedy, Smith (Wireless & IPP Standards) via ipp
- Re: [IPP] Requiring authentication for all IPP op… Michael Sweet via ipp