Skip to content

IPP and OAuth

Smith Kennedy edited this page Sep 2, 2022 · 19 revisions

This page tracks our discussions and consensus regarding IPP and OAuth.

Proposed Work

  • Add discussion of filtering "operations-supported" to the errata update of PWG 5100.11-2010: IPP Job and Printer Extensions - Set 2 (JPS2) (now titled "IPP Enterprise Printing Extensions v2.0 (EPX)") as part of the description of the Get-User-Printer-Attributes operation.
  • Errata update of PWG 5100.18-2015: IPP Shared Infrastructure Extensions v1.0 (INFRA) to address known issues and add explicit OAuth/X.509 support
  • Errata update of PWG 5100.22-2019: IPP System Service v1.0 (SYSTEM) to address known issues and add explicit OAuth/X.509 support
  • Errata update of PWG 5199.10-2019: IPP Authentication Methods v1.0 to amend OAuth recommendations/descriptions
  • New PWG 5199.x: Cloud Printing with IPP Everywhere v1.0 best practice for cloud printing

Slides/Resources

X.509 Certificate Validation

Clients needs to validate the hostname used to connect to the Printer/System with the X.509 certificate. Unlike regular printing, a TOFU policy for self-signed certificates cannot be used due to the greater danger of man-in-the-middle attacks exposing OAuth credentials. Clients should ensure that certs are either signed by a trusted root or a specific self-signed certificate has been explicitly allowed.

Proof Key for Code Exchange

Note: Fill this out.

Proof Key for Code Exchange (RFC 7636) should be used for Client authorization.

Device Authorization Grant

Device Authorization Grant (RFC 8628) can be used to onboard Printers to well-known public Cloud printing services, just as is done for "logging in" for common video streaming platforms. A QR code or URL can be displayed or printed that can be opened on a mobile device to authorize access for the Printer via a user account.

Usage should be documented in a separate "Cloud Printing with IPP Everywhere" best-practice document - System service for the Register-Output-Device operation and any OAuth/X.509 stuff, then INFRA for the Printer/Proxy to grab jobs from the cloud service.

Token Exchange

Token Exchange (RFC 8693) should be used to further minimize disclosure of Client credentials and to validate the Printer/System with the OAuth authorization server. The "resource" value is the "printer-uri" or "system-uri" that was used to connect to the Printer/System. One further benefit is that the issued tokens can have a relatively short lifetime to minimize the chances of tokens being reused for malicious purposes.

Scopes

Scopes can map to IPP access roles (End User, Operator, Administrator), but OAuth doesn't define a set meaning and they get used for many different purposes (roles, access rights, etc.) A Printer/System advertises all of the scopes that are assigned (usually out of band from IPP) for use with that Printer/System in the "oauth-authorization-scope (1setOf name(MAX))" Printer/System Description attribute, and the Client requests those scopes when getting an authorization grant token. The Client can use the Get-User-Printer-Attributes operation to query the subset of operations that are allowed once authorization is granted, but otherwise there is no way to know what the scopes mean. This usage of Get-User-Printer-Attributes is not limited to OAuth.

From a Client perspective, scopes are opaque strings (included in auth request). From a Printer perspective, scopes need to be configured (out of band) to map to access roles or capabilities (e.g. can print color). The Client has to get separate tokens for multiple printers if the scopes and/or authorization servers differ. Token Exchange can reuse Access Token if the scopes are the same.

Recommend OpenID to implement roles/permissions instead of scopes in order to avoid caching issues.

Trusted Platform Module (TPM)

Note: Requires additional research.

TPM 2.0 provides a platform identity device ID and certificate. Once connected to a network, it generates a local device ID derived from the platform and network IDs. Certification guarantees uniqueness and the unique keys are generated during manufacturing with a certificate issued by trusted CA.

  • Mike: What about certificate/key expiration/revocation?
  • Ira: Silent about revocation, root key is immutable, other keys can be regenerated
  • Ira will investigate limitations of certificate life time, renewal

The TPM might be used to generate an X.509 certificate that would be more trustworthy than a self-signed cert (important to OAuth authorization flow to confirm identity of printer)

Updated UML Sequence Diagram (Beta)

PDF Version: ipp-authentication-6-http-oauth2.pdf

SVG Version (should appear in your browser): ipp-authentication-6-http-oauth2-20220825