Subject: RE: [IPP] Proposed errata for rfc3998

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 16 Nov 2011 03:17:06 -0800

Please substitute "section 10.8.3 of rfc3998" for "section 10.8.8 of
rfc3998" below.

Peter Zehler

Xerox Research Center Webster
Email: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of
Zehler, Peter
Sent: Wednesday, November 16, 2011 6:13 AM
To: [email-masked]
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: [email-masked] <mailto:[email-masked]> 
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, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Wed, 16 Nov 2011 07:47:12 -0800

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
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Zehler, Peter
> 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:
> believed to be clean. _______________________________________________
> ipp mailing list
> [email-masked]

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Ira McDonald <[email-masked]>
Date: Wed, 16 Nov 2011 12:15:04 -0500

Hi Mike,

I suggest we either:

(1) "job-originating-user-[name/uri]" applies to the IMMEDIATE upstream
client only (no forwarding behavior) and "originating-requesting-user-name"
name holds the most authenticated original Job owner (the distant guy on
his
cellphone in the Cloud printing scenario) - I think this was the spirit
intended
by RFC 3998 - my preference.

<or>

(2) We leave 3998 alone and say that "originating-requesting-user-name"
is a weak identifier (albeit now enclosed in a TLS tunnel in IPP
Everywhere)
just like "job-name" that's meant to be used for searching and matching in
pools of jobs - not a good idea, because it makes the unverified contents
of
"requesting-user-name" into a sticky Job attribute - a bad precedent IMHO.

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:[email-masked]
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 10:47 AM, Michael Sweet <[email-masked]> wrote:

> 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)
>
> Please substitute “section 10.8.3 of rfc3998” for “section 10.8.8 of
> rfc3998” below.****
> ** **
> ** **
> ** **
> Peter Zehler
>
> Webster NY, 14580-9701****
> ** **
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Zehler,
> Peter
> *Sent:* Wednesday, November 16, 2011 6:13 AM
> *To:* [email-masked]
> *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
>
> Webster NY, 14580-9701****
> ** **
>
> --
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.****
>
> --
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 16 Nov 2011 09:23:50 -0800

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

From: Michael Sweet [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 10:47 AM
To: Zehler, Peter
Cc: [email-masked]
Subject: Re: [IPP] Proposed errata for rfc3998

Pete,

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...)

 

Peter Zehler

All,

Original:

        Description Attribute

Corrected:

        Description Attribute

 

Peter Zehler

believed to be clean.

---

From: "William Wagner" <[email-masked]>
Date: Wed, 16 Nov 2011 12:47:08 -0500

I agree with Ira's option 1 and Pete's take below, which also is my
understanding  of the intent. Obviously, this is unclear (or incorrectly
stated) in the RFC and has probably led to various inconsistent
implementations. The distinction is more significant  as more IPP jobs will
be relayed in the future, and should be clarified.

Bill Wagner

From: [email-masked] [mailto:[email-masked]] On Behalf Of Zehler,
Peter
Sent: Wednesday, November 16, 2011 12:24 PM
To: Michael Sweet
Cc: [email-masked]
Subject: RE: [IPP] Proposed errata for rfc3998

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

Pete,

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.

 

Peter Zehler

From: [email-masked] [mailto:[email-masked]] On Behalf Of Zehler,
Peter
Sent: Wednesday, November 16, 2011 6:13 AM
To: [email-masked]
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:

        Description Attribute

Corrected:

        Description Attribute

 

Peter Zehler

Xerox Research Center Webster
Email:  <mailto:[email-masked]> [email-masked]
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  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean.

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. _______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

 

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean.

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 16 Nov 2011 09:51:04 -0800

Ira,

I suggest:

(1) "requesting-user-name" remains unchanged including the fact that it
may 

be ignored if a trusted value is available.
"job-originating-user-[name/uri]" 

applies to the owner of the job.  In a non-forwarding environment
nothing

changes (i.e. rfc2911).  In forwarding systems (i.e. rfc2998) nothing
changes 

for the initial printer.  The "original-requesting-user-name" is a
plumbing 

element that carries the initial job owner across the forwarding printer
chain.  
"job-originating-user-name" holds the most authenticated original Job
owner 

(the distant guy on his cellphone in the Cloud printing scenario).  The
original

Job owner should be able to list all his jobs on any of the printers in
the chain.

And perform operations on them such as canceling them  - I think this
was 

the spirit intended by RFC 3998.  It aligns 10.8.2 with 10.8.3 and
10.8.4 - my preference.

 

Peter Zehler

From: Ira McDonald [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 12:15 PM
To: Michael Sweet; Ira McDonald
Cc: Zehler, Peter; [email-masked]
Subject: Re: [IPP] Proposed errata for rfc3998

Hi Mike,

I suggest we either:

(1) "job-originating-user-[name/uri]" applies to the IMMEDIATE upstream 
client only (no forwarding behavior) and
"originating-requesting-user-name" 
name holds the most authenticated original Job owner (the distant guy on
his 
cellphone in the Cloud printing scenario) - I think this was the spirit
intended 
by RFC 3998 - my preference.

<or>

(2) We leave 3998 alone and say that "originating-requesting-user-name"
is a weak identifier (albeit now enclosed in a TLS tunnel in IPP
Everywhere) 
just like "job-name" that's meant to be used for searching and matching
in 
pools of jobs - not a good idea, because it makes the unverified
contents of 
"requesting-user-name" into a sticky Job attribute - a bad precedent
IMHO.

Cheers,
- Ira

<http://sites.google.com/site/blueroofmusic> 
<http://sites.google.com/site/highnorthinc> 

On Wed, Nov 16, 2011 at 10:47 AM, Michael Sweet <[email-masked]>
wrote:

Pete,

	Please substitute "section 10.8.3 of rfc3998" for "section
10.8.8 of rfc3998" below.

	Peter Zehler
	
	Xerox Research Center Webster
	Email: [email-masked]
	Voice: (585) 265-8755 <tel:%28585%29%20265-8755> 
	FAX: (585) 265-7441 <tel:%28585%29%20265-7441> 
	US Mail: Peter Zehler
	Xerox Corp.
	800 Phillips Rd.
	M/S 128-25E
	Webster NY, 14580-9701

	From: [email-masked] [mailto:[email-masked]] On Behalf
Of Zehler, Peter
	Sent: Wednesday, November 16, 2011 6:13 AM
	To: [email-masked]
	Subject: [IPP] Proposed errata for rfc3998

	All,

	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

	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

	 

	Peter Zehler
	
	Xerox Research Center Webster
	Email: [email-masked] <mailto:[email-masked]> 
	Voice: (585) 265-8755 <tel:%28585%29%20265-8755> 
	FAX: (585) 265-7441 <tel:%28585%29%20265-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.

 

believed to be clean.

---

From: Michael Sweet <[email-masked]>
Date: Wed, 16 Nov 2011 09:55:23 -0800

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
>

---

From: Ira McDonald <[email-masked]>
Date: Wed, 16 Nov 2011 13:07:37 -0500

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

On Wed, Nov 16, 2011 at 12:55 PM, Michael Sweet <[email-masked]> 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:
>
> 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).
>
> Mike,****
> Fan out and fan in).  On the first system the Job’s
> “original-job-requesting-user-name” and “job-originating-user-name” are
> upstream printer uses its own identity  in  the “requesting-user-name”
> “original-requesting-user-name” as an operational attribute.  The
> downstream printer uses the “requesting-user-name”, or the identity
> 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
> not by the immediate parent (i.e. IPP Printers).****
> ** **
> Pete****
> ** **
> ** **
> Peter Zehler
>
> *From:* Michael Sweet [mailto:[email-masked]]
> *Sent:* Wednesday, November 16, 2011 10:47 AM
> *To:* Zehler, Peter
> *Cc:* [email-masked]
> *Subject:* Re: [IPP] Proposed errata for rfc3998****
> ** **
> Pete,****
> ** **
> original-requesting-user-name and job-originating-user-name?****
> ** **
> provision for it in an IPP job submission)****
> ** **
> the unauthenticated value.****
> ** **
> job-originating-user-uri...)****
> ** **
> On Nov 16, 2011, at 3:17 AM, Zehler, Peter wrote:****
>
>
> ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
> https://www.pwg.org/mailman/listinfo/ipp****
> ** **
> ________________________________________________________________________**
> **
> Michael Sweet, Senior Printing System Engineer, PWG Chair****
> ** **
> ** **
>
>
> ****
> ** **
>
>

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 16 Nov 2011 10:18:48 -0800

Mike,

I can live with #3.  I see no reason to keep
"original-requesting-user-name" around as a job attribute.   I believe
the  updates below represent #3.

Original:

        Description Attribute

Corrected:

10.8.2.  original-requesting-user-name (name(MAX)) Operation Attribute

   "job-originating-user-name" Job Description attribute.

Original:

10.8.4.  job-originating-user-name (name(MAX)) Job Description Attribute

         - Additional Semantics

   The "job-originating-user-name" Job Description attribute (see

   [RFC2911], section 4.3.6) remains as the authenticated original user,

   not the parent Printer's authenticated host, and is forwarded by each

   client without changing the value.

Corrected:

10.8.4.  job-originating-user-name (name(MAX)) Job Description Attribute

         - Additional Semantics

   The "job-originating-user-name" Job Description attribute (see

   [RFC2911], section 4.3.6) remains as the authenticated original user,

   not the parent Printer's authenticated host, and is forwarded by each

   client in the "original-requesting-user-name" operation attribute 

   without changing the value.

Peter Zehler

From: Michael Sweet [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 12:55 PM
To: Zehler, Peter
Cc: [email-masked]
Subject: Re: [IPP] Proposed errata for rfc3998

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:

	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

	Pete

	Peter Zehler

	Pete,

	Seems like the original intent was for
original-requesting-user-name to be the unauthenticated value.

	

	 

	Peter Zehler

	All,

	Original:

	        Description Attribute

	Corrected:

	        Description Attribute

	 

	Peter Zehler

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 16 Nov 2011 10:38:19 -0800

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

Sent: Wednesday, November 16, 2011 1:08 PM

Hi,

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.

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

On Wed, Nov 16, 2011 at 12:55 PM, Michael Sweet <[email-masked]>
wrote:

Pete,

	Mike,

	Pete

	Peter Zehler

	Pete,

	 

	Peter Zehler

	All,

	Original:

	        Description Attribute

	Corrected:

	        Description Attribute

	 

	Peter Zehler

	

	

	 

believed to be clean.

---

From: Ira McDonald <[email-masked]>
Date: Wed, 16 Nov 2011 13:57:56 -0500

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

On Wed, Nov 16, 2011 at 1:38 PM, Zehler, Peter <[email-masked]>wrote:

> Ira,****
> 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
>
> Webster NY, 14580-9701 ****
>
> ** **
>
> *From:* Ira McDonald [mailto:[email-masked]]
> *Sent:* Wednesday, November 16, 2011 1:08 PM
>
> *To:* Michael Sweet; Ira McDonald
> *Cc:* Zehler, Peter; [email-masked]
>
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434****
>
>
>
> ****
>
> On Wed, Nov 16, 2011 at 12:55 PM, Michael Sweet <[email-masked]> wrote:*
> ***
>
> Pete,****
>
> ** **
>
> that is sent to them from the parent printer?****
>
> ** **
>
> should:****
> 1. Remove forwarding of job-originating-user-name entirely,****
>
> 2. Delete original-requesting-user-name entirely, or****
>
> fan-out case (this would, IMHO, be the sanest approach).****
>
> ** **
>
> On Nov 16, 2011, at 9:23 AM, Zehler, Peter wrote:****
>
> Mike,****
>
>  ****
>
> believed to be clean. ****
>
>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 16 Nov 2011 11:29:26 -0800

Pete,

I'm good with the new proposed changes. Thanks!

On Nov 16, 2011, at 10:18 AM, Zehler, Peter wrote:

> Mike,
> I can live with #3.  I see no reason to keep “original-requesting-user-name” around as a job attribute.   I believe the  updates below represent #3.
>  
> Original:
>    “job-originating-user-name” Job Description attribute.
>  
>  
> Original:
>    client in the “original-requesting-user-name” operation attribute

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 16 Nov 2011 11:29:37 -0800

Ira,

I work for Xerox and we build production and enterprise systems.  It is
within those products that the inconsistency within the rfc3998 was at
issue.  I am not proposing anything for cloud printing.  Although in at
least some Cloud Print environments this job forwarding semantics does
not apply anyway.  The job is never forwarded.  The job remains in the
cloud and the printer updates the job status there.  I see no need to
restrict developers from creating insecure unaccountable products.  The
market will decide. 

Pete

Peter Zehler

From: Ira McDonald [mailto:[email-masked]] 
Sent: Wednesday, November 16, 2011 1:58 PM
To: Zehler, Peter; Ira McDonald
Cc: Michael Sweet; [email-masked]
Subject: Re: [IPP] Proposed errata for rfc3998

Hi Pete,

all participate to print the original client's job - letting that
original client

Cheers,
- Ira

On Wed, Nov 16, 2011 at 1:38 PM, Zehler, Peter <[email-masked]>
wrote:

Ira,

Pete

Peter Zehler

Hi,

Cheers,
- Ira

Pete,

	Mike,

	Pete

	Peter Zehler

	Pete,

	 

	Peter Zehler

	All,

	Original:

	        Description Attribute

	Corrected:

	        Description Attribute

	 

	Peter Zehler

	

	

	 

believed to be clean.

---

From: Ira McDonald <[email-masked]>
Date: Wed, 16 Nov 2011 15:14:36 -0500

Hi Pete et al,

Right - if the all Printers in the chain are in the same security domain
and are capable of actually impersonating the original Job owner then
this works.

If the Job submitter (a given Printer) is *not* the Job Owner in some cases,
then this tends to break the access control stuff around cancel.

That is, the intervening Job submitter Printer has to sneak around and use
Admin privilege to cancel a job that *it* in fact submitted - this produces
some
very hard to trace and correlate accounting logs across the multiple
Printers,
I think, but what the heck...

I'm glad Mike's happy with the changes - whatever the result was???

Cheers,
- Ira

On Wed, Nov 16, 2011 at 2:29 PM, Zehler, Peter <[email-masked]>wrote:

> least some Cloud Print environments this job forwarding semantics does not
> apply anyway.  The job is never forwarded.  The job remains in the cloud
> and the printer updates the job status there.  I see no need to restrict
> developers from creating insecure unaccountable products.  The market will
> decide. ****
>
> Pete****
>
> ** **
>
> ** **
>
> Peter Zehler
>
> *Sent:* Wednesday, November 16, 2011 1:58 PM
> *To:* Zehler, Peter; Ira McDonald
> *Cc:* Michael Sweet; [email-masked]
>
> wrote:****
> *Sent:* Wednesday, November 16, 2011 1:08 PM****
>
>
> *To:* Michael Sweet; Ira McDonald****
>
> *Cc:* Zehler, Peter; [email-masked]****
>
>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 16 Nov 2011 12:43:45 -0800

On Nov 16, 2011, at 12:14 PM, Ira McDonald wrote:
> ...

Ira,

The changes are just to drop original-requesting-user-name as a job description attribute and instead define it only as an operation attribute that is used to pass the most-authenticated user name (the job-originating-user-name value) from the parent printer to the child. This avoids having an extra job description attribute and addresses how the job-originating-user-name value on the child printer gets forwarded from the parent (using the original-requesting-user-name operation attribute).