[IPP] Proposed errata for rfc3998

[IPP] Proposed errata for rfc3998

Ira McDonald blueroofmusic at gmail.com
Wed Nov 16 18:07:37 UTC 2011


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/71fb2075/attachment-0001.html>


More information about the ipp mailing list