Subject: Re: [IPP] Updated draft of "IPP Authentication Methods" white paper posted for review

From: "Kennedy, Smith (Wireless & Standards Architec)" <[email-masked]>
Date: Mon, 7 May 2018 19:12:03 +0000

Greetings again,

Following some discussions within HP, I had a couple of points of feedback that I hope we can discuss in the review of this draft.

1. With OAuth2, how can the Printer know the identity of the "most authenticated user" when the authentication is handled by the Authorization Server, not the Printer? In section 3.1.6 of the draft announced below, perhaps some additional provisions or considerations are needed to complete the definition of how OAuth2 can be a viable authentication mechanism for IPP, because if "Get-User-Printer-Attributes" and OAuth2 were to be used together, the Printer could need to be aware of the user's identity.

2. AFAIK IPP or its use of HTTP has no notion of a "session token" (stored in a cookie, etc.) for providing proof of previous authentication in subsequent operation requests. If that is so, then how is the authentication handled with subsequent IPP operations? For instance, if there is a sequence of Validate-Job / Create-Job / Send-Document / Get-Printer-Attributes / Get-Job-Attributes, does the Printer re-challenge the Client each time? Or is there a "session token" that can eliminate those steps for subsequent connections? If the Client has to cache the "username / password" provided by the User for the subsequent operations, what guidance should this white paper provide?

Smith

/**
    Smith Kennedy
    Wireless & Standards Architect - IPG-PPS
    Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF
    Chair, IEEE ISTO Printer Working Group
    HP Inc.
*/

> On Apr 30, 2018, at 1:04 PM, Kennedy, Smith (Wireless & Standards Architec) <[email-masked]> wrote:
> 
> Greetings,
> 
> I have posted an updated draft of "IPP Authentication Methods" for review and possible discussion at the May 2018 F2F in two weeks. It is here:
> 
>   https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-ippauth-20180430.pdf
>   https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-ippauth-20180430.odt
>   https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-ippauth-20180430-rev.pdf
>   https://ftp.pwg.org/pub/pwg/ipp/whitepaper/tb-ippauth-20180430-rev.odt
> 
> Changes include:
> 
> Changed to Apache OpenOffice template. Added Mike Sweet as a co-author since he has contributed a great deal of content to the document. Resolved all “to-do” highlighted areas and resolved issues identified in the February 2018 vF2F minutes (https://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20180207.pdf):
> 
> • Added sequence diagram for X.509 client authentication
> • Added sequence diagram for hybrid 'oauth' / 'digest' authentication
> • Many other changes
> 
> I think we'd like to get closure on this, so if there are any technical issues with the assertions made in this document, please offer feedback but I'd also welcome contributions that resolve the areas of ambiguity.
> 
> Cheers,
> 
> Smith
> 
> /**
>    Smith Kennedy
>    Wireless & Standards Architect - IPG-PPS
>    Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB-IF
>    Chair, IEEE ISTO Printer Working Group
>    HP Inc.
> */
> 
> 
> 
> _______________________________________________
> ipp mailing list
> [email-masked]
> https://www.pwg.org/mailman/listinfo/ipp

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

---

From: Michael Sweet <[email-masked]>
Date: Mon, 07 May 2018 13:11:37 -0700

Smith,

> On May 7, 2018, at 12:12 PM, Kennedy, Smith (Wireless & Standards Architec) <[email-masked]> wrote:
> 
> Greetings again,
> 

So for the purposes of IPP, the "most authenticated user" is the user that is authenticated via HTTP (the user info you get from introspecting the bearer token).  The order is (from most to least):

    1. HTTP Authenticate information (most authenticated)
    2. TLS client certificate information, if any (often only authenticates the Client, not the User)
    3. requesting-user-name (least authenticated)

> 2. AFAIK IPP or its use of HTTP has no notion of a "session token" (stored in a cookie, etc.) for providing proof of previous authentication in subsequent operation requests. If that is so, then how is the authentication handled with subsequent IPP operations?

By the client sending the authentication info in each request.  If the client doesn't send the auth data it gets a 401 challenge.

> For instance, if there is a sequence of Validate-Job / Create-Job / Send-Document / Get-Printer-Attributes / Get-Job-Attributes, does the Printer re-challenge the Client each time? Or is there a "session token" that can eliminate those steps for subsequent connections? If the Client has to cache the "username / password" provided by the User for the subsequent operations, what guidance should this white paper provide?

Basically, once a particular "origin" has challenged the Client, the Client is expected to re-send the auth data in every subsequent request to that origin.  If not, the Printer has to do the 401 challenge dance.  Similarly, some auth schemes (like Digest) will only allow a certain number of reuses before the challenge is issued again.

CUPS' http_t object caches both the username/password and Authentication header value (for Negotiate, Bearer, etc.), so usually you just have to supply credentials once per print job.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer