Hi Pete,
That proxy via the same directory service in the same security domain
under a TLS tunnel is one thing.
But how do you propose that it could possibly apply in the case that
one or more Cloud providers and and an entirely different target domain
all participate to print the original client's job - letting that original
client
directly cancel jobs on those downstream printers is going to cause real
headaches of accounting and security.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Wed, Nov 16, 2011 at 1:38 PM, Zehler, Peter <Peter.Zehler at xerox.com>wrote:
> Ira,****
>> Well I guess we just have broken systems here that use the same backend
> directory service. And does that mean schemes such as OAUTH are broken as
> well? I’m not advocating doing strong downstream or passing client secrets
> along. All that is required in a fan out environment is the child trust
> the parent. If it is a secure system it certainly won’t depend on the
> “requesting-user-name” and it will have a special administrative role
> assigned to the parent printer. The initial printer can authenticate the
> client. If access is permitted at the target printer then the target
> printer has to tie into the same authorization domain as the initial
> printer.****
>> Pete****
>> ** **
>> ** **
>> Peter Zehler
>> Xerox Research Center Webster
> Email: Peter.Zehler at Xerox.com> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701 ****
>> ** **
>> *From:* Ira McDonald [mailto:blueroofmusic at gmail.com]
> *Sent:* Wednesday, November 16, 2011 1:08 PM
>> *To:* Michael Sweet; Ira McDonald
> *Cc:* Zehler, Peter; ipp at pwg.org>> *Subject:* Re: [IPP] Proposed errata for rfc3998****
>> ** **
>> Hi,
>> OK - I'm mostly with Mike here.
>> Also, I'm pretty strongly *not* with Bill and Pete - the forwarding
> Printers
> OWN the downstream Jobs and have the Job submission and access
> control and upstream notification receipt rights.
>> The original Job owner (on the cellphone) queries the *original* Job at
> the first Printer (the Cloud Print Service, typically) to see the rolled-up
> and summarized results of the downstream Job processing.
>> Letting the original Job submitter cancel Jobs on way downstream Printers
> is a severe security violation that breaks any possible scheme of access
> control.
>> Where would the authentication credentials come when the downstream
> Jobs were created by the intervening Printers.
>> Because I assure you that the Printers *cannot* have the private key of
> the
> original Job owner and cannot keep doing strong downstream authentication
> in so-called proxy operations (and the assumption that simple username and
> password can just be sent forward out-of-band is hopelessly broken).
>> Cheers,
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - TCG Embedded Systems Hardcopy SG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
>http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc> mailto:blueroofmusic at gmail.com> Winter 579 Park Place Saline, MI 48176 734-944-0094
> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434****
>>>> ****
>> On Wed, Nov 16, 2011 at 12:55 PM, Michael Sweet <msweet at apple.com> wrote:*
> ***
>> Pete,****
>> ** **
>> My point about forwarding is that the mechanism for authenticating the
> original-requesting-user-name and job-originating-user-name values over IPP
> is undefined. How/why do the child printers implicitly trust everything
> that is sent to them from the parent printer?****
>> ** **
>> But again, the current wording makes original-requesting-user-name and
> job-originating-user-name distinctly different:
> original-requesting-user-name is the value that was supplied by the client
> while job-originating-user-name is the most authenticated name. Your
> proposed change would effectively make them the same, in which case we
> should:****
>> ** **
>> 1. Remove forwarding of job-originating-user-name entirely,****
>> 2. Delete original-requesting-user-name entirely, or****
>> 3. Make original-requesting-user-name exclusively an operation attribute
> and use it to pass the forwarded job-originating-user-name value in the
> fan-out case (this would, IMHO, be the sanest approach).****
>> ** **
>> On Nov 16, 2011, at 9:23 AM, Zehler, Peter wrote:****
>> Mike,****
>> ****
>> The semantics are limited to Job forwarding systems of printers (i.e. IPP
> Fan out and fan in). On the first system the Job’s
> “original-job-requesting-user-name” and “job-originating-user-name” are
> populated with the same value. Per rfc2911 that value is the most
> authenticated printable name that it can obtain from the authentication
> service over which the IPP operation was received. Only if such is not
> available, does the Printer object use the value supplied by the client in
> the "requesting-user-name". On the next hop is where things diverge. The
> upstream printer uses its own identity in the “requesting-user-name”
> operational attribute. It also passes along the
> “original-requesting-user-name” as an operational attribute. The
> downstream printer uses the “requesting-user-name”, or the identity
> obtained from a trusted protocol layer, to insure the request is from a
> configured upstream printer. The downstream printer then copies over the
> “original-job-requesting-user-name” operational attribute to the job object
> AND to the job object’s “job-originating-user-name”. In other words the
> child job is owned by the initial submitting user throughout the chain and
> not by the immediate parent (i.e. IPP Printers).****
>> ****
>> Pete****
>> ****
>> ****
>> Peter Zehler
>> Xerox Research Center Webster
> Email: Peter.Zehler at Xerox.com> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701****
>> ****
>> *From:* Michael Sweet [mailto:msweet at apple.com]
> *Sent:* Wednesday, November 16, 2011 10:47 AM
> *To:* Zehler, Peter
> *Cc:* ipp at pwg.org> *Subject:* Re: [IPP] Proposed errata for rfc3998****
>> ****
>> Pete,****
>> ****
>> If we make this change, then what is the difference between
> original-requesting-user-name and job-originating-user-name?****
>> ****
>> Section 10.8.4 (re)defines job-originating-user-name as the authenticated
> original user and whose value is supposed to be forwarded by each client
> unchanged... (something I am not 100% happy with since there is no
> provision for it in an IPP job submission)****
>> ****
>> Seems like the original intent was for original-requesting-user-name to be
> the unauthenticated value.****
>> ****
>> (and now I go off to add some text for this to JPS3 for
> job-originating-user-uri...)****
>> ****
>> On Nov 16, 2011, at 3:17 AM, Zehler, Peter wrote:****
>> ** **
>> Please substitute “section 10.8.3 of rfc3998” for “section 10.8.8 of
> rfc3998” below.****
>> ****
>> ****
>> ****
>> Peter Zehler
>> Xerox Research Center Webster
> Email: Peter.Zehler at Xerox.com> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701****
>> ****
>> *From:* ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] *On Behalf Of *Zehler,
> Peter
> *Sent:* Wednesday, November 16, 2011 6:13 AM
> *To:* IPP at pwg.org> *Subject:* [IPP] Proposed errata for rfc3998****
>> ****
>> All,****
>> ****
>> Section 10.8.2 covering “original-requesting-user-name” is a bit misleading. The issue is that the Job owner is not always the same as the “requesting-user-name”. When forwarding jobs from one printer to another the “original-requesting-user-name” is the most authenticated printable name that can be obtained. As stated in section 10.8.8 of rfc3998: “The "job-originating-user-name" Job Description attribute (see [RFC2911], section 4.3.6) remains as the authenticated original user”. This is inconsistent with section 10.8.2 as currently written. Below is my proposed change to section 10.8.2.****
>> ****
>> Original:****
>> 10.8.2. original-requesting-user-name (name(MAX)) Operation and Job****
>> Description Attribute****
>> ****
>> The operation attribute containing the user name of the original****
>> user; i.e., corresponding to the "requesting-user-name" operation****
>> attribute (see [RFC2911], section 3.2.1.1) that the original client****
>> supplied to the first Printer object. The Printer copies the****
>> "original-requesting-user-name" operation attribute to the****
>> corresponding Job Description attribute.****
>> ****
>> Corrected:****
>> 10.8.2. original-requesting-user-name (name(MAX)) Operation and Job****
>> Description Attribute****
>> ****
>> The operation attribute containing the user name of the original****
>> user; i.e., corresponding to the "job-originating-user-name" Job****
>> attribute (see [RFC2911], section 4.3.6) that identifies the Job****
>> owner on the first Printer object. The Printer copies the****
>> "original-requesting-user-name" operation attribute to the****
>> corresponding Job Description attribute.****
>> ****
>> ****
>> Peter Zehler
>> Xerox Research Center Webster
> Email: Peter.Zehler at Xerox.com> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701****
>> ****
>>> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.****
>>> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp****>> ****
>> ________________________________________________________________________**
> **
>> Michael Sweet, Senior Printing System Engineer, PWG Chair****
>> ****
>> ****
>> ** **
>> ****
>> ** **
>> ________________________________________________________________________**
> **
>> Michael Sweet, Senior Printing System Engineer, PWG Chair****
>> ** **
>>> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. ****
>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp****>> ** **
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20111116/f409d028/attachment-0001.html>