Subject: [IPP] Updated stable draft of IPP Authentication Methods posted

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Mon, 4 Mar 2019 17:22:50 +0000

Greetings,

Thanks to all who provided feedback on the 20190117 draft of IPP Authentication Methods. Since I received valuable non-editorial feedback in addition to editorial feedback on the draft from the PWG Last Call, I have produced a new revision that hopefully resolves all the issues and can be used in a second last call. The new draft is here:

   https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190304.odt <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190304.odt>
   https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190304.pdf <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190304.pdf>
   https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190304-rev.odt <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190304-rev.odt>
   https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190304-rev.pdf <https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190304-rev.pdf>

I included the contents of my LCRC document in the "Change History" section. If those that submitted comments could review this draft offline and evaluate whether my changes have fixed their issues, I'd appreciate it.

Smith

/**
    Smith Kennedy
    HP Inc.
*/

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

---

From: Michael Sweet via ipp <[email-masked]>
Date: Mon, 04 Mar 2019 13:14:11 -0500

Smith,

> On Mar 4, 2019, at 12:22 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <[email-masked]> wrote:
> 
> Greetings,
> 

The -rev version is (as usual) a bit hard to follow, but I like the changes.  We normally do the LCRC comments in a separate txt file, but I'm fine with it being in the changes section for now.  Process/3.0 doesn't require a particular format or filename, just that all comments and their resolutions be listed for review.

Feedback:

One addition I'd like to see to see for the "requesting-user-name" method is a note that some Clients use a constant identity as a privacy defense (e.g., "mobile" from iOS Clients) when sending requests, so from a Printer's perspective this method is basically useless.  In the context of GDPR, this falls under a need for explicit consent - a password challenge or Client UI requesting permission to provide the real user name is required.  At Apple we decided to always hide the requesting user on iOS for basic privacy reasons, relying on authentication where such information is genuinely needed.

In the general client recommendations (section 14.2?), you say:

    Client security considerations (section 18.2) should also be followed.

Since we have a lowercase "should" here, perhaps reword this as:

    Also see section 18.2 for Client security considerations and recommendations.

There is a similar statement in the general printer recommendation (section 14.4?), which should probably read "Also see section 18.4 for Printer security considerations and recommendations." (right now it says Client...)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Mon, 4 Mar 2019 19:49:04 +0000

> On Mar 4, 2019, at 11:14 AM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 
>> On Mar 4, 2019, at 12:22 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Greetings,
>> 
>>    https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190304.odt <https://protect-us.mimecast.com/s/D3aXC1wq8qiGREkwuL5aci?domain=ftp.pwg.org>
>>    https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190304.pdf <https://protect-us.mimecast.com/s/zuXzC2kr5rf3jERoI1JDrB?domain=ftp.pwg.org>
>>    https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190304-rev.odt <https://protect-us.mimecast.com/s/u2zDC31v5viKBRGYI21Si0?domain=ftp.pwg.org>
>>    https://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippauth-20190304-rev.pdf <https://protect-us.mimecast.com/s/wmRLC4xw7wu5o7mAuWGutv?domain=ftp.pwg.org>
>> 
> The -rev version is (as usual) a bit hard to follow, but I like the changes.

Totally agree!

https://bugs.documentfoundation.org/show_bug.cgi?id=123848 <https://bugs.documentfoundation.org/show_bug.cgi?id=123848>

>  We normally do the LCRC comments in a separate txt file, but I'm fine with it being in the changes section for now.  Process/3.0 doesn't require a particular format or filename, just that all comments and their resolutions be listed for review.
> 
> Feedback:
> 

Do you want this in section 4.2 "The 'requesting-user-name' IPP Authentication Method" (using numbering from the non-rev documents), or in 5.1.1. "General Recommendations" (for Clients), or 7.2. "Client Security Considerations"? There seems to be two different statements: what is done in the field, and what a Client or Printer ought to do.

>     Also see section 18.2 for Client security considerations and recommendations.

OK. Will fix that now and re-post once I am clear about what to do about the "anonymized 'requesting-user-name'" issue above and where it should live.

> There is a similar statement in the general printer recommendation (section 14.4?), which should probably read "Also see section 18.4 for Printer security considerations and recommendations." (righ…

Will fix that one too.

---

From: Michael Sweet via ipp <[email-masked]>
Date: Mon, 04 Mar 2019 16:10:21 -0500

Smith,

> On Mar 4, 2019, at 2:49 PM, Kennedy, Smith (Wireless & Standards Architect) <[email-masked]> wrote:
> 
> 
> 
>> On Mar 4, 2019, at 11:14 AM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Smith,
>> 

I was thinking of this being in section 4.2.  As far as the general recommendations for clients, I think we need to make a note of privacy concerns, .i.e., recommend that Clients don't just throw the current username in there without getting explicit permission from the User.

---

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Mon, 4 Mar 2019 21:25:20 +0000

> On Mar 4, 2019, at 2:10 PM, Michael Sweet <[email-masked]> wrote:
> 

I am fine with that - how's this for an updated section 4.2:

4.2. The 'requesting-user-name' IPP Authentication Method

The 'requesting-user-name' IPP Authentication Method [RFC8011] indicates that the Client is to provide the “requesting-user-name” operation attribute [RFC8011] in its IPP operation request. The Printer uses this unauthenticated name as the identity of the User operating the Client. This method is not recommended if job accounting or access authorization is important, since the Printer does not challenge the Client to prove the identity claimed in the “requesting-user-name”. Some Clients always send a fixed identity name (e.g. “mobile”) as a privacy defense when sending requests. As such, from a Printer's perspective, this method is increasingly undependable.

I wonder if we need to call out the notion of authentication as a form of explicit consent to share information, especially within the context of privacy concerns such as GDPR compliance? Where might we put that? The start of Section 4 "Client Authentication Methods"? Or down in Security Considerations?

---

From: Michael Sweet via ipp <[email-masked]>
Date: Mon, 04 Mar 2019 19:37:59 -0500

Smith,

> On Mar 4, 2019, at 4:25 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <[email-masked]> wrote:
> 
> 
> 
>> On Mar 4, 2019, at 2:10 PM, Michael Sweet <[email-masked] <mailto:[email-masked]>> wrote:
>> 

I would add "also" to the sentence, e.g., "Also, some Clients always send ..."

> I wonder if we need to call out the notion of authentication as a form of explicit consent to share information, especially within the context of privacy concerns such as GDPR compliance? Where mig…

Right now I hesitate to put that wording in this document.  If IDS is going to tackle the privacy/information gathering problem, I think we are probably better off deferring that discussion to their work since there isn't a lot we can say in a few sentences here.

But FWIW, I think an authentication challenge and the subsequent providing of credentials does constitute explicit consent WRT the username and password; there is still the issue of *informed consent* to deal with - how does the user know why they are being asked for a username and password?

(I also feel like we may end up with an update to my IPP Privacy Attributes document at some point...)

---

From: "Kennedy, Smith \(Wireless & Standards Architect\) via ipp" <[email-masked]>
Date: Tue, 5 Mar 2019 15:52:14 +0000

OK, I added that into an updated 20190304 draft, which I just posted.

> On Mar 4, 2019, at 5:37 PM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
> 
>> On Mar 4, 2019, at 4:25 PM, Kennedy, Smith (Wireless & Standards Architect) via ipp <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>