summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7472.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7472.txt')
-rw-r--r--doc/rfc/rfc7472.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc7472.txt b/doc/rfc/rfc7472.txt
new file mode 100644
index 0000000..c1f5d75
--- /dev/null
+++ b/doc/rfc/rfc7472.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) I. McDonald
+Request for Comments: 7472 High North, Inc.
+Updates: 2910, 2911 M. Sweet
+Category: Standards Track Apple, Inc.
+ISSN: 2070-1721 March 2015
+
+
+ Internet Printing Protocol (IPP) over HTTPS Transport Binding
+ and the 'ipps' URI Scheme
+
+Abstract
+
+ This document defines the Internet Printing Protocol (IPP) over HTTPS
+ transport binding and the corresponding 'ipps' URI scheme, which is
+ used to designate the access to the network location of a secure IPP
+ print service or a network resource managed by such a service.
+
+ This document defines an alternate IPP transport binding to that
+ defined in the original IPP URL Scheme (RFC 3510), but this document
+ does not update or obsolete RFC 3510.
+
+ This document updates RFCs 2910 and 2911.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7472.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McDonald & Sweet Standards Track [Page 1]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McDonald & Sweet Standards Track [Page 2]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Structure of This Document .................................4
+ 1.2. Rationale for This Document ................................5
+ 2. Conventions Used in This Document ...............................5
+ 2.1. Requirements Language ......................................5
+ 2.2. Printing Terminology .......................................5
+ 2.3. Abbreviations ..............................................6
+ 3. IPP over HTTPS Transport Binding ................................7
+ 4. Definition of 'ipps' URI Scheme .................................8
+ 4.1. Applicability of 'ipps' URI Scheme .........................8
+ 4.2. Syntax of 'ipps' URI Scheme ................................8
+ 4.3. Associated Port for 'ipps' URI Scheme .....................10
+ 4.4. Character Encoding of 'ipps' URI Scheme ...................10
+ 4.5. Examples of 'ipps' URIs ...................................11
+ 4.6. Comparisons of 'ipps' URIs ................................12
+ 5. IANA Considerations ............................................12
+ 6. Security Considerations ........................................13
+ 6.1. Problem Statement .........................................13
+ 6.1.1. Targets of Attacks .................................14
+ 6.1.2. Layers of Attacks ..................................14
+ 6.2. Attacks and Defenses ......................................14
+ 6.2.1. Faked 'ipps' URI ...................................15
+ 6.2.2. Unauthorized Access by IPP Client ..................15
+ 6.2.3. Compromise at Application Layer Gateway ............15
+ 6.2.4. No Client Authentication for 'ipps' URI ............15
+ 6.3. TLS Version Requirements ..................................16
+ 7. References .....................................................16
+ 7.1. Normative References ......................................16
+ 7.2. Informative References ....................................17
+ Acknowledgments ...................................................19
+ Authors' Addresses ................................................19
+
+1. Introduction
+
+ This document defines the Internet Printing Protocol (IPP) over HTTPS
+ transport binding and the corresponding 'ipps' URI scheme, which is
+ used to designate the access to the network location of a secure IPP
+ print service or a network resource managed by such a service.
+
+ This document has been submitted to the IETF by the Internet Printing
+ Protocol Working Group (WG) of the IEEE-ISTO Printer Working Group,
+ as part of their PWG "IPP Everywhere" (PWG 5100.14) project for
+ secure mobile printing with vendor-neutral Client software.
+
+
+
+
+
+
+McDonald & Sweet Standards Track [Page 3]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+ This document defines an alternate IPP transport binding to that
+ defined in the original IPP URL Scheme [RFC3510], but this document
+ does not update or obsolete [RFC3510].
+
+ This document updates:
+
+ a) "Internet Printing Protocol/1.1: Encoding and Transport"
+ [RFC2910], by extending Section 4 ("Encoding of Transport Layer"),
+ Section 5 ("IPP URL Scheme"); and Section 8.2 ("Using IPP with
+ TLS") to add the new standard URI scheme of 'ipps' for IPP
+ Printers; and
+
+ b) "Internet Printing Protocol/1.1: Model and Semantics" [RFC2911],
+ by extending Section 4.1.6 ("uriScheme") and Section 4.4.1
+ ("printer-uri-supported") to add the new standard URI scheme of
+ 'ipps' for IPP Printers.
+
+ The following versions of IPP are currently defined:
+
+ a) 1.0 in [RFC2566] (obsolete);
+ b) 1.1 in [RFC2911];
+ c) 2.0 in [PWG5100.12];
+ d) 2.1 in [PWG5100.12]; and
+ e) 2.2 in [PWG5100.12].
+
+ Overview information about IPP is available in Section 1 of
+ [RFC2911], Section 1 of [RFC3196], and Section 1 of PWG "IPP Version
+ 2.0 Second Edition (IPP/2.0 SE)" [PWG5100.12].
+
+1.1. Structure of This Document
+
+ This document contains the following sections:
+
+ Section 2 defines the conventions and terms used throughout the
+ document.
+
+ Section 3 defines the IPP over HTTPS transport binding.
+
+ Section 4 defines the 'ipps' URI scheme.
+
+ Sections 5 and 6 contain IANA and security considerations,
+ respectively.
+
+ Section 7 contains references.
+
+
+
+
+
+
+
+McDonald & Sweet Standards Track [Page 4]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+1.2. Rationale for This Document
+
+ The 'ipps' URI scheme was defined for the following reasons:
+
+ 1) Some existing IPP Client and IPP Printer implementations of
+ "Upgrading to TLS Within HTTP/1.1" [RFC2817] are flawed and
+ unreliable, although this is not due to specification defects in
+ [RFC2817] itself.
+
+ 2) Some existing IPP Client and IPP Printer implementations of HTTP
+ upgrade [RFC2817] do not perform an upgrade at the beginning of
+ every HTTP [RFC7230] connection; instead, they only shift to
+ secure IPP for selected IPP operations (inherently dangerous
+ behavior on the same underlying TCP [RFC793] connection).
+
+ 3) IPP Printer server-mandated HTTP upgrade [RFC2817] can still lead
+ to exposure of IPP Client data if the Expect request header is not
+ used -- basically, the IPP Client can send its whole Print-Job
+ request before the IPP Printer has a chance to respond and say,
+ "Wait! You need to encrypt first!".
+
+2. Conventions Used in This Document
+
+2.1. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+2.2. Printing Terminology
+
+ The reader of this document needs to be familiar with the printing
+ terms defined in "Internet Printing Protocol/1.1: Model and
+ Semantics" [RFC2911] as well as the following:
+
+ IPP Client: The software (on some hardware platform) that submits IPP
+ Job creation and IPP Printer and IPP Job management operations via
+ the IPP over HTTP transport binding defined in the IPP/1.1
+ Encoding and Transport document [RFC2910] and/or the IPP over
+ HTTPS transport binding defined in Section 3 of this specification
+ to an IPP Printer (print spooler, print gateway, or physical
+ printing device).
+
+ IPP Job: The set of attributes and documents for one print job
+ instantiated in an IPP Printer.
+
+ IPP Job object: Synonym for IPP Job.
+
+
+
+
+McDonald & Sweet Standards Track [Page 5]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+ IPP Printer: The software (on some hardware platform) that receives
+ IPP Job creation and IPP Printer and IPP Job management operations
+ via the IPP over HTTP transport binding defined in the IPP/1.1
+ Encoding and Transport document [RFC2910] and/or the IPP over
+ HTTPS transport binding defined in Section 3 of this specification
+ from an IPP Client.
+
+ IPP Printer object: Synonym for IPP Printer.
+
+ 'ipps' URI: A URI using the 'ipps' URI scheme defined in Section 4
+ of this specification.
+
+2.3. Abbreviations
+
+
+ This document makes use of the following abbreviations (given with
+ their expanded forms and references for further reading):
+
+ ABNF - Augmented Backus-Naur Form [STD68]
+
+ ASCII - American Standard Code for Information Interchange [ASCII]
+
+ HTTP - HyperText Transfer Protocol [RFC7230]
+
+ HTTPS - HTTP over TLS [RFC7230]
+
+ IANA - Internet Assigned Numbers Authority
+ <http://www.iana.org>
+
+ IEEE - Institute of Electrical and Electronics Engineers
+ <http://www.ieee.org>
+
+ IESG - Internet Engineering Steering Group
+ <http://www.ietf.org/iesg/>
+
+ IPP - Internet Printing Protocol [RFC2911] and [PWG5100.12]
+ <http://www.pwg.org/ipp/>
+
+ ISTO - IEEE Industry Standards and Technology Organization
+ <http://www.ieee-isto.org/>
+
+ LPD - Line Printer Daemon Protocol [RFC1179]
+
+ PWG - IEEE-ISTO Printer Working Group
+ <http://www.pwg.org>
+
+ RFC - Request for Comments
+ <http://www.rfc-editor.org>
+
+
+
+McDonald & Sweet Standards Track [Page 6]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+ TCP - Transmission Control Protocol [RFC793]
+
+ TLS - Transport Layer Security [RFC5246]
+
+ URI - Uniform Resource Identifier [STD66]
+
+ URL - Uniform Resource Locator [STD66]
+
+ UTF-8 - Unicode Transformation Format - 8-bit [STD63]
+
+3. IPP over HTTPS Transport Binding
+
+ This document defines the following alternate IPP over HTTPS
+ transport binding for the abstract protocol defined in "Internet
+ Printing Protocol/1.1: Model and Semantics" [RFC2911] and IEEE-ISTO
+ PWG "IPP Version 2.0 Second Edition (IPP/2.0 SE)" [PWG5100.12].
+
+ When using an 'ipps' URI, an IPP Client MUST establish an IPP
+ application-layer connection according to the following sequence:
+
+ 1) The IPP Client selects an 'ipps' URI value from a "printer-uri-
+ supported" Printer attribute [RFC2911], a directory entry,
+ discovery info, a web page, etc.;
+
+ 2) The IPP Client converts the 'ipps' URI to an 'https' URI [RFC7230]
+ (replacing 'ipps' with 'https' and inserting the port number from
+ the URI or port 631 if the URI doesn't include an explicit port
+ number);
+
+ 3) The IPP Client establishes an HTTPS [RFC7230] secure session layer
+ connection to the target endpoint; and
+
+ 4) The IPP Client sends requests to and receives responses from the
+ target IPP application-layer resource over the HTTPS [RFC7230]
+ secure session layer connection using the POST method defined in
+ [RFC7231].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McDonald & Sweet Standards Track [Page 7]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+4. Definition of 'ipps' URI Scheme
+
+4.1. Applicability of 'ipps' URI Scheme
+
+ Per PWG "IPP Everywhere" [PWG5100.14], in IPP exchanges, the 'ipps'
+ URI scheme MUST only be used:
+
+ a) To specify an absolute URI for IPP secure print services and their
+ associated network resources;
+
+ b) To specify the use of the abstract protocol defined in "Internet
+ Printing Protocol/1.1: Model and Semantics" [RFC2911] and IEEE-
+ ISTO PWG "IPP Version 2.0 Second Edition (IPP/2.0 SE)"
+ [PWG5100.12]; and
+
+ c) To specify the use of the transport binding defined in this
+ document.
+
+ The 'ipps' URI scheme allows an IPP Client to choose an appropriate
+ IPP secure print service (for example, from a directory). The IPP
+ Client can establish an HTTPS connection to the specified IPP secure
+ print service. The IPP Client can send IPP requests (for example,
+ Print-Job requests) and receive IPP responses over that HTTPS
+ connection.
+
+ See: Section 4.2 ("Syntax of 'ipps' URI Scheme") of this document.
+
+ See: Section 4.4.1 ("printer-uri-supported") in [RFC2911].
+
+ See: Section 5 ("IPP URL Scheme") in [RFC2910].
+
+ See: Section 4 ("IPP Standards") of IEEE-ISTO PWG "IPP Version 2.0
+ Second Edition (IPP/2.0 SE)" [PWG5100.12].
+
+4.2. Syntax of 'ipps' URI Scheme
+
+ The abstract protocol defined in [RFC2911] places a limit of 1023
+ octets (NOT characters) on the length of a URI.
+
+ See: "Uniform Resource Identifier (URI): Generic Syntax" [STD66].
+
+ Per PWG "IPP Everywhere" [PWG5100.14], for compatibility with
+ existing IPP implementations, IPP Printers SHOULD NOT generate 'ipp'
+ [RFC3510] or 'ipps' URI (or allow administrators to configure)
+ lengths above 255 octets, because many older IPP Client
+ implementations do not properly support these lengths.
+
+
+
+
+
+McDonald & Sweet Standards Track [Page 8]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+ Per PWG "IPP Everywhere" [PWG5100.14], in IPP exchanges, 'ipps' URIs
+ MUST be represented in absolute form. Absolute URIs always begin
+ with a scheme name followed by a colon. For definitive information
+ on URI syntax and semantics, see "Uniform Resource Identifier (URI):
+ Generic Syntax and Semantics" [STD66]. This specification adopts the
+ definitions of "host", "port", and "query" from [STD66]. This
+ specification adopts the definition of "absolute-path" from
+ [RFC7230].
+
+ The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows:
+
+ ipps-uri =
+ "ipps:" "//" host [ ":" port ] [ absolute-path [ "?" query ]]
+
+ Per [RFC2910], if the port is empty or not given, then port 631 MUST
+ be used.
+
+ See: Section 4.3 ("Associated Port for 'ipps' URI Scheme") in this
+ document.
+
+ The semantics are that the identified resource (see [RFC7230]) is
+ located at the IPP secure print service listening for HTTPS
+ connections on that port of that host; and the Request-URI for the
+ identified resource is 'absolute-path'.
+
+ Note: The higher-level "authority" production is not imported from
+ [STD66], because it includes an optional "userinfo" component that
+ cannot be used in 'ipps' URIs.
+
+ Note: The "query" production does not have defined semantics in IPP
+ and was never used in examples in the IPP/1.1 Encoding and Transport
+ document [RFC2910] or the original IPP URL Scheme [RFC3510]. The
+ "query" is retained here for consistency, but IPP Clients SHOULD
+ avoid its use (because the semantics would be implementation
+ defined).
+
+ Note: Per PWG "IPP Everywhere" [PWG5100.14], literal IPv4 or IPv6
+ addresses SHOULD NOT be used in 'ipps' URIs, because:
+
+ a) IP addresses are often changed after network device installation
+ (for example, based on DHCP reassignment after a power cycle);
+
+ b) IP addresses often don't map simply to security domains;
+
+ c) IP addresses are difficult to validate with X.509 server
+ certificates (because they do not map to common name or alternate
+ name attributes); and
+
+
+
+
+McDonald & Sweet Standards Track [Page 9]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+ d) IP link local addresses are not "portable" due to link identity.
+
+ Per [RFC2910], if the 'absolute-path' is not present in an IPP URI,
+ it MUST be given as "/" when used as a Request-URI for a resource
+ (see [RFC7230]). An 'ipps' URI is transformed into an 'https' URI by
+ replacing "ipps:" with "https:" and inserting port 631 (if an
+ explicit 'port' is not present in the original 'ipps' URI).
+
+ See: Section 4.3 ("Associated Port for 'ipps' URI Scheme") in this
+ document.
+
+4.3. Associated Port for 'ipps' URI Scheme
+
+ Per [RFC2910], all 'ipps' URIs that do NOT explicitly specify a port
+ MUST be resolved to IANA-assigned well-known port 631, already
+ registered in [PORTREG] by [RFC2910].
+
+ Note: Per direction of the IESG, as described in [RFC2910], port 631
+ is used for all IPP connections (with or without TLS [RFC5246]).
+ Therefore, port 631 is used for both 'ipp' [RFC3510] and 'ipps' URIs,
+ which both refer to an IPP Printer or a network resource managed by
+ an IPP Printer. IPP Printer implementors can refer to the CUPS
+ [CUPS] source code for an example of incoming connection handling for
+ the dual use of port 631.
+
+ See: IANA Port Numbers Registry [PORTREG].
+
+ See: [RFC2910].
+
+4.4. Character Encoding of 'ipps' URI Scheme
+
+ Per PWG "IPP Everywhere" [PWG5100.14], 'ipps' URIs MUST:
+
+ a) Use the UTF-8 [STD63] charset for all components; and
+
+ b) Use [STD66] rules for percent encoding data octets outside the US-
+ ASCII-coded character set [ASCII].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McDonald & Sweet Standards Track [Page 10]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+4.5. Examples of 'ipps' URIs
+
+ The following are examples of well-formed 'ipps' URIs for IPP
+ Printers (for example, to be used as protocol elements in 'printer-
+ uri' operation attributes of Print-Job request messages):
+
+ ipps://example.com/
+ ipps://example.com/ipp
+ ipps://example.com/ipp/faxout
+ ipps://example.com/ipp/print
+ ipps://example.com/ipp/scan
+ ipps://example.com/ipp/print/bob
+ ipps://example.com/ipp/print/ira
+
+ Note: The use of an explicit 'ipp' path component followed by
+ explicit 'print', 'faxout', 'scan', or other standard or vendor
+ service component is best practice per [PWG5100.14], [PWG5100.15],
+ and [PWG5100.17].
+
+ Each of the above URIs is a well-formed URI for an IPP Printer and
+ each would reference a logically different IPP Printer, even though
+ some of those IPP Printers might share the same host system. Note
+ that 'print' might represent some grouping of IPP Printers (for
+ example, a load-balancing spooler), while the 'bob' or 'ira' last
+ path components might represent two different physical printer
+ devices, or 'bob' and 'ira' might represent separate human recipients
+ on the same physical printer device (for example, a physical printer
+ supporting two job queues). Regardless, both 'bob' and 'ira' would
+ behave as different and independent IPP Printers.
+
+ The following are examples of well-formed 'ipps' URIs for IPP
+ Printers with (optional) ports and paths:
+
+ ipps://example.com/
+ ipps://example.com/ipp/print
+ ipps://example.com:631/ipp/print
+
+ The first and second 'ipps' URIs above will be resolved to port 631
+ (IANA-assigned well-known port for IPP). The second and third 'ipps'
+ URIs above are equivalent (see Section 4.6).
+
+ See: Sections 4.2 ("Syntax of 'ipps' URI Scheme") and 4.3
+ ("Associated Port for 'ipps' URI Scheme") in this document.
+
+
+
+
+
+
+
+
+McDonald & Sweet Standards Track [Page 11]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+4.6. Comparisons of 'ipps' URIs
+
+ Per PWG "IPP Everywhere" [PWG5100.14], when comparing two 'ipps' URIs
+ to decide whether or not they match, an IPP Client MUST use the same
+ rules as those defined for 'http' and 'https' URI comparisons in
+ [RFC7230], with the following single exception:
+
+ - A port that is empty or not given MUST be treated as equivalent to
+ the well-known port for that 'ipps' URI (port 631).
+
+ See: Section 4.3 ("Associated Port for 'ipps' URI Scheme") in this
+ document.
+
+ See: Section 2.7.3 ("http and https URI Normalization and
+ Comparison") in [RFC7230].
+
+5. IANA Considerations
+
+ IANA has registered the new keyword value 'ipps' for the IPP Printer
+ "printer-uri-supported" attribute in the IANA IPP Registry [IPPREG],
+ per Section 6.2 ("Attribute Extensibility") of [RFC2911] as follows:
+
+ IANA has registered the 'ipps' URI scheme using the following
+ template, which conforms to [BCP35].
+
+ URI scheme name: ipps
+
+ Status: Permanent
+
+ URI scheme syntax: See Section 4.2 of RFC 7472.
+
+ URI scheme semantics: The 'ipps' URI scheme is used to designate
+ secure IPP Printer objects (print spoolers, print gateways, print
+ devices, etc.) on Internet hosts accessible using the IPP enhanced
+ to support guaranteed data integrity and negotiable data privacy
+ using TLS [RFC5246] as specified in HTTP/1.1 [RFC7230].
+
+ Encoding Considerations: See Section 4.4 of RFC 7472.
+
+ Applications/protocols that use this URI scheme name: The 'ipps' URI
+ scheme is intended to be used by applications that need to access
+ secure IPP Printers using the IPP enhanced to support guaranteed
+ data integrity and negotiable data privacy using TLS [RFC5246] as
+ specified in HTTP/1.1 [RFC7230]. Such applications may include
+ (but are not limited to) IPP-capable web browsers, IPP Clients
+ that wish to print a file, and servers (for example, print
+ spoolers) wishing to forward a Job for processing.
+
+
+
+
+McDonald & Sweet Standards Track [Page 12]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+ Interoperability Considerations: The widely deployed, open source IPP
+ print service CUPS [CUPS] (on most UNIX, Linux, and Apple OS X
+ systems) has supported 'ipps' URI for several years before the
+ publication of this document. PWG "IPP Everywhere" [PWG5100.14]
+ (IPP secure, mobile printing extensions) requires the use of
+ 'ipps' URI for mandatory data integrity and negotiable data
+ confidentiality.
+
+ Security Considerations: See Section 6 of RFC 7472.
+
+ Contact: Ira McDonald <blueroofmusic@gmail.com>,
+ Michael Sweet <msweet@apple.com>
+
+ Author/Change controller: IESG
+
+ References: RFCs 2910, 2911, and 7472; IEEE-ISTO PWG 5100.12.
+
+6. Security Considerations
+
+6.1. Problem Statement
+
+ Powerful mobile devices (laptops, tablets, smartphones, etc.) are now
+ commonly used to access enterprise and Cloud print services across
+ the public Internet. This is the primary use case for PWG "IPP
+ Everywhere" [PWG5100.14], which has already been adopted by operating
+ system and printer vendors and several other public standards bodies.
+ End-user and enterprise documents and user privacy-sensitive
+ information are at greater risk than ever before. This IPP-over-
+ HTTPS transport binding and 'ipps' URI scheme specification was
+ defined to enable high availability combined with secure operation in
+ this dynamic environment (for example, wireless hotspots in hotels,
+ airports, and restaurants).
+
+ See: Section 1 ("Introduction") of [PWG5100.14].
+
+ See: Section 3.1 ("Rationale") of [PWG5100.14].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McDonald & Sweet Standards Track [Page 13]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+6.1.1. Targets of Attacks
+
+ A network print spooler (logical printer) or print device (physical
+ printer) is potentially subject to attacks, which may target:
+
+ a) The network (to compromise the routing infrastructure, for
+ example, by creating congestion);
+
+ b) The Internet Printing Protocol (IPP) [RFC2911] (for example, to
+ compromise the normal behavior of IPP);
+
+ c) The print job metadata (for example, to extract privacy-sensitive
+ information from the job submission request or via query of the
+ job on the IPP Printer); or
+
+ d) The print document content itself (for example, to steal the data
+ or to corrupt the documents being transferred).
+
+6.1.2. Layers of Attacks
+
+ Attacks against print services can be launched:
+
+ a) Against the network infrastructure (for example, TCP [RFC793]
+ congestion control);
+
+ b) Against the IPP data flow itself (for example, by sending forged
+ packets or forcing TLS [RFC5246] version downgrade); or
+
+ c) Against the IPP operation parameters (for example, by corrupting
+ requested document processing attributes).
+
+6.2. Attacks and Defenses
+
+ This 'ipps' URI Scheme specification adds the following additional
+ security considerations to those described in [RFC7230], [RFC2910],
+ [RFC2911], [RFC5246], [RFC7230], [PWG5100.12], and [STD66].
+
+ See: Section 8 ("Security Considerations") in [RFC2910].
+
+ See: Section 8 ("Security Considerations") in [RFC2911].
+
+ See: Appendix D ("Implementation Notes"), Appendix E ("Backward
+ Compatibility"), and Appendix F ("Security Analysis") of
+ [RFC5246].
+
+ See: Section 10 ("Security Considerations") in [PWG5100.12].
+
+ See: Section 7 ("Security Considerations") in [STD66].
+
+
+
+McDonald & Sweet Standards Track [Page 14]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+6.2.1. Faked 'ipps' URI
+
+ An 'ipps' URI might be faked to point to a rogue IPP secure print
+ service, thus collecting confidential job metadata or document
+ contents from IPP Clients.
+
+ Due to administrator reconfiguration or physical relocation of an IPP
+ Printer, a former literal IPv4 or IPv6 address might no longer be
+ valid. See Section 4.2 ("Syntax of 'ipps' URI Scheme") for the
+ recommendation against the use of literal IP addresses in 'ipps' URI.
+
+ Server authentication mechanisms and security mechanisms specified in
+ IPP/1.1 Encoding and Transport [RFC2910], HTTP/1.1 [RFC7230], and
+ TLS/1.2 [RFC5246] can be used to address this threat.
+
+6.2.2. Unauthorized Access by IPP Client
+
+ An 'ipps' URI might be used to access an IPP secure print service by
+ an unauthorized IPP Client, for example, extracting privacy-sensitive
+ information such as "job-originating-user-name" job metadata defined
+ in [RFC2911].
+
+ Client authentication mechanisms and security mechanisms specified in
+ IPP/1.1 Encoding and Transport [RFC2910], HTTP/1.1 [RFC7230], and
+ TLS/1.2 [RFC5246] can be used to address this threat.
+
+6.2.3. Compromise at Application Layer Gateway
+
+ An 'ipps' URI might be used to access an IPP secure print service at
+ a print protocol application layer gateway (for example, an IPP to
+ LPD [RFC1179] gateway [RFC2569]), potentially causing silent
+ compromise of IPP security mechanisms.
+
+ There is no general defense against this threat by an IPP Client.
+ System administrators SHOULD avoid such configurations.
+
+6.2.4. No Client Authentication for 'ipps' URI
+
+ An 'ipps' URI does not define parameters to specify the required IPP
+ Client authentication mechanism (for example, 'certificate' as
+ defined in Section 4.4.2 ("uri-authentication-supported") of
+ [RFC2911]).
+
+ An IPP Client SHOULD first use service discovery or directory
+ protocols (e.g., the "Lightweight Directory Access Protocol (LDAP):
+ Schema for Printer Services" [RFC3712]) or directly send an IPP Get-
+ Printer-Attributes operation to the target IPP Printer to read
+
+
+
+
+McDonald & Sweet Standards Track [Page 15]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+ "printer-uri-supported", "uri-authentication-supported", and "uri-
+ security-supported" attributes to discover the required IPP Client
+ authentication and security mechanisms for each supported URI.
+
+6.3. TLS Version Requirements
+
+ Per PWG "IPP Everywhere" [PWG5100.14] (and in accordance with
+ security best practices and all existing deployments of the 'ipps'
+ URI scheme), IPP Clients and IPP Printers that support this
+ specification MUST use TLS/1.2 [RFC5246] or a higher version, for all
+ 'ipps' secure transport layer connections.
+
+ Implementors will find useful advice in the "Recommendations for
+ Secure Use of TLS and DTLS" [TLSBCP].
+
+7. References
+
+7.1. Normative References
+
+ [ASCII] American National Standards Institute, "Coded Character
+ Set -- 7-bit American Standard Code for Information
+ Interchange", ANSI X3.4, 1986.
+
+ [PWG5100.12] Bergman, R., Lewis, H., McDonald, I., and M. Sweet,
+ "Internet Printing Protocol", Version 2.0, Second
+ Edition (IPP/2.0 SE), PWG 5100.12, February 2011,
+ <http://www.pwg.org/standards.html>.
+
+ [PWG5100.14] McDonald, I. and M. Sweet, "PWG IPP Everywhere", PWG
+ 5100.14, January 2013,
+ <http://www.pwg.org/standards.html>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2910] Herriot, R., Ed., Butler, S., Moore, P., Turner, R., and
+ J. Wenn, "Internet Printing Protocol/1.1: Encoding and
+ Transport", RFC 2910, September 2000,
+ <http://www.rfc-editor.org/info/rfc2910>.
+
+ [RFC2911] Hastings, T., Ed., Herriot, R., deBry, R., Isaacson, S.,
+ and P. Powell, "Internet Printing Protocol/1.1: Model
+ and Semantics", RFC 2911, September 2000,
+ <http://www.rfc-editor.org/info/rfc2911>.
+
+
+
+
+
+
+McDonald & Sweet Standards Track [Page 16]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
+ Security (TLS) Protocol Version 1.2", RFC 5246, August
+ 2008, <http://www.rfc-editor.org/info/rfc5246>.
+
+ [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
+ Transfer Protocol (HTTP/1.1): Message Syntax and
+ Routing", RFC 7230, June 2014,
+ <http://www.rfc-editor.org/info/rfc7230>.
+
+ [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
+ Transfer Protocol (HTTP/1.1): Semantics and Content",
+ RFC 7231, June 2014,
+ <http://www.rfc-editor.org/info/rfc7231>.
+
+ [STD63] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003,
+ <http://www.rfc-editor.org/info/sstd63>.
+
+ [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC
+ 3986, January 2005,
+ <http://www.rfc-editor.org/info/std66>.
+
+ [STD68] Crocker, D., Ed., and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", STD 68, RFC 5234, January
+ 2008, <http://www.rfc-editor.org/info/std68>.
+
+7.2. Informative References
+
+ [BCP35] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
+ Registration Procedures for New URI Schemes", BCP 35,
+ RFC 4395, February 2006,
+ <http://www.rfc-editor.org/info/bcp35>.
+
+ [CUPS] Apple, "CUPS", Version 2.0.2, <https://www.cups.org/>.
+
+ [IPPREG] Internet Assigned Numbers Authority (IANA) Registries,
+ "Internet Printing Protocol (IPP) Registrations",
+ <http://www.iana.org/assignments/ipp-registrations/>.
+
+ [PORTREG] Internet Assigned Numbers Authority (IANA) Registries,
+ "Service Name and Transport Protocol Port Number
+ Registry",
+ <http://www.iana.org/assignments/port-numbers>.
+
+ [PWG5100.15] M. Sweet, "PWG IPP FaxOut Service", PWG 5100.15, June
+ 2014, <http://www.pwg.org/standards.html>.
+
+
+
+
+McDonald & Sweet Standards Track [Page 17]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+ [PWG5100.17] P. Zehler, "PWG IPP Scan Service", PWG 5100.17,
+ September 2014, <http://www.pwg.org/standards.html>.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981,
+ <http://www.rfc-editor.org/info/rfc793>.
+
+ [RFC1179] McLaughlin, L., "Line printer daemon protocol", RFC
+ 1179, August 1990,
+ <http://www.rfc-editor.org/info/rfc1179>.
+
+ [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and
+ P. Powell, "Internet Printing Protocol/1.0: Model and
+ Semantics", RFC 2566, April 1999,
+ <http://www.rfc-editor.org/info/rfc2566>.
+
+ [RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J.
+ Martin, "Mapping between LPD and IPP Protocols", RFC
+ 2569, April 1999,
+ <http://www.rfc-editor.org/info/rfc2569>.
+
+ [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
+ HTTP/1.1", RFC 2817, May 2000,
+ <http://www.rfc-editor.org/info/rfc2817>.
+
+ [RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
+ Holst, "Internet Printing Protocol/1.1: Implementor's
+ Guide", RFC 3196, November 2001,
+ <http://www.rfc-editor.org/info/rfc3196>.
+
+ [RFC3510] Herriot, R. and I. McDonald, "Internet Printing
+ Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003,
+ <http://www.rfc-editor.org/info/rfc3510>.
+
+ [RFC3712] Fleming, P. and I. McDonald, "Lightweight Directory
+ Access Protocol (LDAP): Schema for Printer Services",
+ RFC 3712, February 2004,
+ <http://www.rfc-editor.org/info/rfc3712>.
+
+ [TLSBCP] Scheffer, Y., Holz, R., and P. Saint-Andre,
+ "Recommendations for Secure Use of TLS and DTLS", Work
+ in Progress, draft-ietf-uta-tls-bcp, December 2014.
+
+
+
+
+
+
+
+
+
+McDonald & Sweet Standards Track [Page 18]
+
+RFC 7472 IPP over HTTPS and 'ipps' URI Scheme March 2015
+
+
+Acknowledgments
+
+ This document has been submitted to the IETF by the Internet Printing
+ Protocol Working Group of the IEEE-ISTO Printer Working Group, as
+ part of their PWG IPP Everywhere [PWG5100.14] project for secure
+ mobile printing with vendor-neutral Client software.
+
+ This document defines an alternate IPP transport binding to that
+ defined in the original IPP URL Scheme [RFC3510], but this document
+ does not update or obsolete [RFC3510].
+
+ Thanks to Claudio Allochio, Jari Arrko, Spencer Dawkins, Adrian
+ Farrel, Tom Hastings, Bjoern Hoerhmann, Smith Kennedy, Graham Klyne,
+ Barry Leiba, S. Moonesamy, Kathleen Moriarty, Sandra Murphy, Tom
+ Petch, Pete Resnick, Benson Schliesser, Robert Sparks, Jerry
+ Thrasher, Mykyta Yevstifeyev, Pete Zehler, and the members of the
+ IEEE-ISTO PWG IPP WG.
+
+Authors' Addresses
+
+ Ira McDonald
+ High North, Inc.
+ 221 Ridge Ave
+ Grand Marais, MI 49839
+ United States
+
+ Phone: +1 906-494-2434
+ EMail: blueroofmusic@gmail.com
+
+
+ Michael Sweet
+ Apple, Inc.
+ 1 Infinite Loop, M/S 111-HOMC
+ Cupertino, CA 95014
+ United States
+
+ EMail: msweet@apple.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McDonald & Sweet Standards Track [Page 19]
+