Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme
updates
Extracted elements (25)
Literal IP addresses are discouraged in 'ipps' URIs because they are often changed after network device installation (e.g., DHCP reassignment), don't map simply to security domains, are difficult to validate with X.509 certificates, and link-local addresses are not portable.
The higher-level 'authority' production from RFC 3986 is not imported for 'ipps' URIs because it includes an optional 'userinfo' component that cannot be used in 'ipps' URIs.
The 'ipps' URI scheme was created because existing implementations of HTTP upgrade (RFC 2817) were flawed: some only shifted to secure IPP for selected operations on the same TCP connection (inherently dangerous), and printer-mandated upgrades could expose client data if the Expect header was not used.
Port 631 is used for all IPP connections (with or without TLS), per IESG direction. Therefore port 631 is used for both 'ipp' and 'ipps' URIs. CUPS source code is referenced as an example of incoming connection handling for this dual use.
The 'query' component in 'ipps' URIs has no defined semantics in IPP and was never used in examples in RFC 2910 or RFC 3510. It is retained for consistency, but IPP Clients SHOULD avoid its use.
The widely deployed open source IPP print service CUPS has supported 'ipps' URI for several years before publication of this document, providing pre-existing implementation experience.
An IPP Client SHOULD first use service discovery or directory protocols or send an IPP Get-Printer-Attributes operation to read 'printer-uri-supported', 'uri-authentication-supported', and 'uri-security-supported' attributes before connecting, to discover required authentication and security mechanisms.
If the port is empty or not given in an 'ipps' URI, port 631 MUST be used. All 'ipps' URIs without an explicit port MUST be resolved to IANA-assigned well-known port 631.
IPP Clients and IPP Printers that support this specification MUST use TLS/1.2 (RFC 5246) or a higher version for all 'ipps' secure transport layer connections.
IPP Printers SHOULD NOT generate 'ipp' or 'ipps' URIs (or allow administrators to configure) lengths above 255 octets, because many older IPP Client implementations do not properly support these lengths.
'ipps' URIs MUST be represented in absolute form in IPP exchanges. If the 'absolute-path' is not present, it MUST be given as '/' when used as a Request-URI.
'ipps' URIs MUST use the UTF-8 charset for all components and MUST use RFC 3986 rules for percent encoding data octets outside the US-ASCII character set.
Literal IPv4 or IPv6 addresses SHOULD NOT be used in 'ipps' URIs, because IP addresses are often changed after installation, don't map simply to security domains, are difficult to validate with X.509 certificates, and link-local addresses are not portable.
System administrators SHOULD avoid configurations involving application layer gateways (e.g., IPP to LPD gateways) accessed via 'ipps' URIs, as these can cause silent compromise of IPP security mechanisms.
The 'ipps' URI scheme MUST only be used to specify absolute URIs for IPP secure print services, to specify use of the abstract IPP protocol, and to specify use of the HTTPS transport binding defined in this document.
When comparing two 'ipps' URIs, an IPP Client MUST use the same rules as for 'http' and 'https' URI comparisons in RFC 7230, except that a port that is empty or not given MUST be treated as equivalent to port 631.
When using an 'ipps' URI, an IPP Client MUST establish a connection by: selecting the URI, converting it to an 'https' URI (replacing 'ipps' with 'https' and inserting port 631 if not specified), establishing an HTTPS secure session, and sending requests using the POST method.
The IPP over HTTPS transport binding requires the IPP Client to convert an 'ipps' URI to an 'https' URI by replacing 'ipps' with 'https', insert port 631 if not explicit, establish HTTPS, and communicate using HTTP POST.
The 'ipps' URI scheme is defined for secure IPP print services. Its ABNF syntax is: ipps-uri = "ipps:" "//" host [ ":" port ] [ absolute-path [ "?" query ]]. The userinfo component from RFC 3986 is explicitly excluded.
IANA registered the 'ipps' URI scheme as a permanent URI scheme. The scheme designates secure IPP Printer objects accessible via IPP over HTTPS using TLS for data integrity and negotiable data privacy.
IANA registered the new keyword value 'ipps' for the IPP Printer 'printer-uri-supported' attribute in the IANA IPP Registry, per Section 6.2 of RFC 2911.
An 'ipps' URI might be faked to point to a rogue IPP secure print service, collecting confidential job metadata or document contents. Server authentication mechanisms in RFC 2910, RFC 7230, and TLS/1.2 can be used to address this threat.
An 'ipps' URI might be used to access an IPP secure print service by an unauthorized IPP Client, extracting privacy-sensitive information such as 'job-originating-user-name'. Client authentication mechanisms in RFC 2910, RFC 7230, and TLS/1.2 can address this threat.
Attacks against print services can target the network infrastructure, the IPP data flow (e.g., by sending forged packets or forcing TLS version downgrade), or the IPP operation parameters (e.g., by corrupting requested document processing attributes).
The 'ipps' URI scheme does not define parameters to specify the required IPP Client authentication mechanism. IPP Clients should query the printer for 'uri-authentication-supported' to discover the required authentication mechanisms.