[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 09 10 11
12 13 14 15 16 17 18 RFC 7472
Network Working Group Ira McDonald
INTERNET-DRAFT High North Inc
Updates: 2910, 2911 (if approved) Michael Sweet
Intended Status: Standards Track Apple Inc
Expires: 19 March 2014 19 September 2013
IPP over HTTPS Transport Binding and 'ipps' URI Scheme
draft-mcdonald-ipps-uri-scheme-08.txt
Abstract
This memo defines the Internet Printing Protocol (IPP) over HTTPS
transport binding and the corresponding 'ipps' URI scheme, that is
used to designate the access to the network location of a secure IPP
print service or a network resource (for example, a print job)
managed by such a service.
This memo is published by the IETF on behalf of the Internet Printing
Protocol Working Group of the IEEE-ISTO Printer Working Group.
This memo updates RFC 2910 and RFC 2911.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on 19 March 2014.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
McDonald, Sweet Expires 19 March 2014 [Page 1]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
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.
Table of Contents
1. Introduction ............................................... 3
1.1. Structure of this document ............................. 3
1.2. Rationale for this document ............................ 4
2. Conventions Used in this Document .......................... 4
3. IPP Transport Bindings ..................................... 5
3.1. IPP over HTTP Transport Binding (Informative) .......... 5
3.2. IPP over HTTPS Transport Binding (Normative) ........... 6
4. Definition of 'ipps' URI Scheme ............................ 7
4.1. Applicability of 'ipps' URI Scheme ..................... 7
4.2. Syntax of 'ipps' URI Scheme ............................ 7
4.3. Associated Port for 'ipps' URI Scheme .................. 9
4.4. Associated MIME Type for 'ipps' URI Scheme ............. 9
4.5. Character Encoding of 'ipps' URI Scheme ................ 9
4.6. Examples of 'ipps' URI ................................. 9
4.6.1. Examples of 'ipps' URI for Printers ................ 9
4.6.2. Examples of 'ipps' URI for Jobs .................... 10
4.7. Comparisons of 'ipps' URI .............................. 11
5. Applicability of this Specification ........................ 11
5.1. Applicability to IPP Clients ........................... 11
5.2. Applicability to IPP Printers .......................... 12
6. IANA Considerations ........................................ 13
7. Security Considerations .................................... 14
8. References ................................................. 15
8.1. Normative References ................................... 15
8.2. Informative References ................................. 16
9. Appendix A - Acknowledgments ............................... 17
10. Appendix B - Abbreviations Used in this Document .......... 17
11. Appendix X - Change History ............................... 18
12. Authors' Addresses ........................................ 21
McDonald, Sweet Expires 19 March 2014 [Page 2]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
1. Introduction
This memo defines the Internet Printing Protocol (IPP) over HTTPS
transport binding and the corresponding 'ipps' URI scheme, that is
used to designate the access to the network location of a secure IPP
print service or a network resource (for example, a print job)
managed by such a service. Therefore, this memo defines 'ipps' URI
scheme applicability, associated port, associated MIME type,
character encoding, and syntax.
This memo updates:
a) IPP/1.1 Encoding and Transport [RFC2910], by extending section 4
'Encoding of the Transport Layer', section 5 'IPP URL Scheme', and
section 8.2 'Using IPP with TLS';
b) IPP/1.1 Model and Semantics [RFC2911], by extending section 4.1.6
'uriScheme' and section 4.4.1 'printer-uri-supported'; and
c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by
extending section 4 'IPP Standards' and section 10 'Security
Considerations'.
This memo is published by IETF on behalf of 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.
The following versions of IPP are currently defined:
- 1.0 in [RFC2566] (obsolete)
- 1.1 in [RFC2911]
- 2.0 in [PWG5100.12]
- 2.1 in [PWG5100.12]
- 2.2 in [PWG5100.12]
Overview information about IPP is available in section 1 of RFC 2911
[RFC2911], section 1 of RFC 3196 [RFC3196], and section 1 of PWG IPP
Version 2.0 Second Edition [PWG5100.12].
1.1. Structure of this document
This document contains the following sections: Section 2 defines the
conventions used throughout the document.
Section 3 defines the IPP over HTTPS transport binding, after first
summarizing the original IPP over HTTP transport binding.
Section 4 defines the 'ipps' URI scheme.
Section 5 defines the applicability of this specification to IPP
McDonald, Sweet Expires 19 March 2014 [Page 3]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
Clients and IPP Printers.
Sections 6 and 7 contain IANA and security considerations,
respectively.
Section 8 contains references.
Appendix A contains acknowledgments and Appendix B explains
abbreviations used in this document.
1.2. Rationale for this document
The 'ipps' URI scheme was defined for the following reasons:
1) Many existing IPP Client and IPP Printer implementations of
Upgrading to TLS Within HTTP/1.1 [RFC 2817] are flawed and
unreliable.
2) Some existing IPP Client and IPP Printer implementations of HTTP
Upgrade [RFC 2717] do not perform upgrade at the beginning of
every HTTP connection, but instead only shift to secure IPP for
selected IPP operations (inherently dangerous behavior on the same
underlying TCP connection).
3) IPP Printer server-mandated HTTP Upgrade [RFC 2817] 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
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 RFC 2119 [RFC2119].
The reader of this document should be familiar with the terminology
in IPP/1.1 Model and Semantics [RFC2911] (particularly, with the
definition of 'IPP Objects', 'Printer Object' and 'Job Object'),
abbreviations described in Appendix B and the following terms.
In this document, "IPP Client" means the software (on some hardware
platform) that submits, monitors, and/or manages secure print jobs
via the IPP/1.1 Encoding and Transport [RFC2910] or IEEE-ISTO PWG IPP
Version 2.0 Second Edition [PWG5100.12] to a secure print spooler,
secure print gateway, or secure physical printing device.
McDonald, Sweet Expires 19 March 2014 [Page 4]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
In this document, "IPP Printer object" means the software (on some
hardware platform) that receives secure print jobs and/or secure
printer/job operations via the IPP/1.1 Encoding and Transport
[RFC2910] or IEEE-ISTO PWG IPP Version 2.0 Second Edition
[PWG5100.12] from an "IPP Client".
In this document, "IPP Printer" is a synonym for "IPP Printer
object".
In this document, "IPP Job object" means the set of attributes and
documents for one secure print job instantiated on an "IPP Printer".
In this document, "IPP Job" is a synonym for "IPP Job object".
In this document, "'ipps' URI" means a URI using the 'ipps' URI
scheme defined in section 4 of this specification.
3. IPP Transport Bindings
3.1. IPP over HTTP Transport Binding (Informative)
This section is informative.
When using an 'ipp' URI [RFC3510], an IPP Client establishes an IPP
application layer connection according to the following sequence:
1) The IPP Client selects an 'ipp' URI value from
"printer-uri-supported" Printer attribute [RFC2911], a directory
entry, discovery info, a web page, etc.;
2) The IPP Client converts the 'ipp' URI to an 'http' URI (replacing
'ipp' with 'http' and inserting port 631);
3) The IPP Client establishes a TCP [STD7] reliable transport layer
connection to the target endpoint - see section 3.4 'Establishing
a connection' in TCP [STD7];
4) The IPP Client establishes an HTTP [RFC2616] session layer
connection to the target endpoint - see section 8 'Connections' in
HTTP/1.1 [RFC2616];
5) Optionally, either the IPP Client upgrades to TLS within HTTP/1.1
per section 3 'Client Requested Upgrade to HTTP over TLS' of
[RFC2817] or the IPP Printer upgrades to TLS within HTTP/1.1 per
section 4 'Server Requested Upgrade to HTTP over TLS' of
McDonald, Sweet Expires 19 March 2014 [Page 5]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
[RFC2817], in order to establish a TLS Protocol [RFC5246] secure
transport sublayer within the original TCP/HTTP connection - per
the "uri-security-supported" (section 4.4.3 in [RFC2911]) Printer
attribute value parallel to the "printer-uri-supported" (see
section 4.4.1 in [RFC2911]) value that matches this connection;
and
6) The IPP Client sends IPP application layer requests to and
receives responses from the IPP Printer over the HTTP [RFC2616]
session layer connection using the POST method defined in section
9.5 of HTTP/1.1 [RFC2616], as specified in section 4 'Encoding of
Transport Layer' in IPP/1.1 Encoding and Transport [RFC2910].
See: Section 8 'Security Considerations' in [RFC2817].
3.2. IPP over HTTPS Transport Binding (Normative)
This section is normative.
This document defines the following IPP over HTTPS alternate
transport binding for the abstract protocol defined in IPP/1.1 Model
and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version 2.0 Second
Edition [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
"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
(replacing 'ipps' with 'https' and inserting port 631);
3) The IPP Client establishes a TCP [STD7] reliable transport layer
connection to the target endpoint - see section 3.4 'Establishing
a connection' in TCP [STD7];
4) The IPP Client establishes a TLS [RFC5246] secure transport layer
connection to the target endpoint - see section 7 'The TLS
Handshaking Protocols' in TLS [RFC5246];
5) The IPP Client establishes an HTTPS [RFC2818] secure session layer
connection over the TLS [RFC5246] secure transport layer to the
target endpoint; and
6) The IPP Client sends IPP application layer requests to and
receives responses from the IPP Printer over the HTTPS [RFC2818]
secure session layer connection using the POST method defined in
McDonald, Sweet Expires 19 March 2014 [Page 6]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
section 9.5 of HTTP/1.1 [RFC2616], as specified in section 4
'Encoding of Transport Layer' in IPP/1.1 Encoding and Transport
[RFC2910].
See: Section 'Security Considerations' in [RFC2818].
4. Definition of 'ipps' URI Scheme
4.1. Applicability of 'ipps' URI Scheme
The 'ipps' URI scheme MUST only be used to specify absolute URI
(relative 'ipps' URI are not allowed) for IPP secure print services
and their associated network resources. The 'ipps' URI scheme MUST
only be used to specify the use of the abstract protocol defined in
IPP/1.1 Model and Semantics [RFC2911] and IEEE-ISTO PWG IPP Version
2.0 Second Edition [PWG5100.12] over an HTTPS [RFC2818] transport, as
defined in this specification. Any other transport binding for IPP
would require a different URI scheme.
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 protocol requests (for
example, 'Print-Job' requests) and receive IPP protocol responses
over that HTTPS connection.
See: Section 3.2 of this document.
See: Section 4.4.1 'printer-uri-supported' in IPP/1.1 Model and
Semantics [RFC2911].
See: Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport
[RFC2910].
See: Section 4 'IPP Standards' and section 10 'Security
Considerations' of IEEE-ISTO PWG IPP Version 2.0 Second Edition
[PWG5100.12].
4.2. Syntax of 'ipps' URI Scheme
The abstract protocol defined in IPP/1.1 Model and Semantics
[RFC2911] places a limit of 1023 octets (NOT characters) on the
length of a URI.
See: Section 4.1.5 'uri' in [RFC2911].
McDonald, Sweet Expires 19 March 2014 [Page 7]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
Note: IPP Printers ought to be cautious about depending on URI
lengths above 255 bytes, because some older IPP Client
implementations might not properly support these lengths.
'ipps' URI MUST be represented in absolute form. Absolute URI MUST
always begin with a scheme name followed by a colon. For definitive
information on URI syntax and semantics, see "Uniform Resource
Identifiers (URI) Generic Syntax and Semantics" [STD66]. This
specification adopts the definitions of "host", "port",
"path-absolute", and "query" from [STD66].
The 'ipps' URI scheme syntax in ABNF [STD68] is defined as follows:
ipps-uri =
"ipps:" "//" host [ ":" port ] [ path-absolute [ "?" query ]]
Note: The higher-level production "authority" is not imported from
[STD66], because it includes an optional "userinfo" component which
cannot be used in 'ipps' URI.
If the port is empty or not given, then port 631 MUST be used. The
semantics are that the identified resource (see section 5.1.2 of
[RFC2616]) 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 'path-absolute'.
Note: Literal IPv4 or IPv6 addresses SHOULD NOT be used in 'ipps'
URI, because:
a) IP addresses are often changed after network device installation
(e.g., 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
d) IPv6 link local addresses are not "portable" due to link identity
If the 'path-absolute' is not present in the URI, it MUST be given as
"/" when used as a Request-URI for a resource (see section 5.1.2 of
[RFC2616]).
An 'ipps' URI is transformed into an 'https' URI by replacing "ipps:"
with "https:" and inserting port 631 (if the 'port' is not present in
the original 'ipps' URI).
See: Section 3.2 of this document.
McDonald, Sweet Expires 19 March 2014 [Page 8]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
4.3. Associated Port for 'ipps' URI Scheme
All 'ipps' URI which do NOT explicitly specify a port MUST be
resolved to IANA-assigned well-known port 631, as registered in
[PORTREG].
See: IANA Port Numbers Registry [PORTREG].
See: IPP/1.1 Encoding and Transport [RFC2910].
4.4. Associated MIME Type for 'ipps' URI Scheme
All 'ipps' URI MUST be used to specify secure print services which
support the "application/ipp" MIME media type as registered in
[MIMEREG] for IPP protocol requests and responses.
See: IANA MIME Media Types Registry [MIMEREG].
See: IPP/1.1 Encoding and Transport [RFC2910].
4.5. Character Encoding of 'ipps' URI Scheme
'ipps' URI MUST use the UTF-8 [STD63] charset for all components.
'ipps' URI MUST use [STD66] rules for percent encoding data octets
outside the US-ASCII coded character set [ASCII].
4.6. Examples of 'ipps' URI
4.6.1. Examples of 'ipps' URI for Printers
The following are examples of well-formed 'ipps' URI 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/tiger
ipps://example.com/ipp/fox
ipps://example.com/ipp/tiger/bob
ipps://example.com/ipp/tiger/ira
McDonald, Sweet Expires 19 March 2014 [Page 9]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
Each of the above URI are well-formed URI for IPP Printers and each
would reference a logically different IPP Printer, even though some
of those IPP Printers might share the same host system. The 'bob' or
'ira' last path components might represent two different physical
printer devices, while 'tiger' might represent some grouping of IPP
Printers (for example, a load-balancing spooler). Or the 'bob' and
'ira' last path components might represent separate human recipients
on the same physical printer device (for example, a physical printer
supporting two job queues). In either case, both 'bob' and 'ira'
would behave as different and independent IPP Printers.
The following are examples of well-formed 'ipps' URI for IPP Printers
with (optional) ports and paths:
ipps://example.com
ipps://example.com/ipp
ipps://example.com:631/ipp
The first and second 'ipps' URI above MUST be resolved to port 631
(IANA assigned well-known port for IPP). The second and third 'ipps'
URI above are equivalent (see section 4.7 below).
4.6.2. Examples of 'ipps' URI for Jobs
The following are examples of well-formed 'ipps' URI for IPP Jobs
(for example, to be used as protocol elements in 'job-uri' attributes
of 'Print-Job' response messages):
ipps://example.com/ipp/123
ipps://example.com/ipp/tiger/job123
'ipps' URI for Jobs are valid and meaningful only until Job
completion and possibly an implementation defined optional period of
persistence after Job completion (see IPP Model [RFC2911]).
Ambiguously, section 4.3.1 'job-uri' of IPP Model [RFC2911] states
that:
"the precise format of a Job URI is implementation dependent."
Thus, the relationship between the value of the "printer-uri"
operation attribute used in a 'Print-Job' request and the value of
the "job-uri" attribute returned in the corresponding 'Print-Job'
response is entirely implementation dependent. Also, section 4.3.3
'job-printer-uri' of IPP Model [RFC2911] states that the
'job-printer-uri' attribute of a Job object:
McDonald, Sweet Expires 19 March 2014 [Page 10]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
"permits a client to identify the Printer object that created this
Job object when only the Job object's URI is available to the
client."
However, the above statement is erroneous, because the transform from
a URI for an IPP Job to the corresponding URI for the associated IPP
Printer is unspecified in either IPP/1.1 Model and Semantics
[RFC2911] or IPP/1.1 Encoding and Transport [RFC2910].
IPP Printers that implement this specification SHOULD only generate
'ipps' URI for Jobs (for example, in the "job-uri" attribute in a
'Print-Job' response) by appending exactly one path component to the
corresponding 'ipps' URI for the associated Printer (for
interoperability).
4.7. Comparisons of 'ipps' URI
When comparing two 'ipps' URI to decide if they match or not, an IPP
Client MUST use the same rules as those defined for 'http' URI
comparisons in [RFC2616] as updated by the 'https' URI scheme
[RFC2818], with the sole following 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 3.2.3 'URI Comparison' in [RFC2616].
See: Section 2.4 'URI Format' in [RFC2818].
5. Applicability of this Specification
5.1. Applicability to IPP Clients
IPP Clients that implement this specification:
a) MUST support the IPP over HTTPS transport binding defined in
section 3.2 and the 'ipps' URI scheme defined in section 4;
b) MUST support the IPP over HTTP transport binding with TLS defined
in section 8.2 'Using IPP with TLS' of IPP/1.1 Encoding and
Transport [RFC2910] (for interoperability with existing IPP
implementations);
c) MUST only send IPP protocol connections to IANA assigned
well-known port 631 or to the explicit port specified in a given
McDonald, Sweet Expires 19 March 2014 [Page 11]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
'ipps' URI;
d) MUST only send 'ipps' URI used as protocol elements in outgoing
IPP protocol request messages that conform to the ABNF specified
in section 4.2 of this document (for example, in the "printer-uri"
operation attribute in a 'Print-Job' request);
e) MUST only convert 'ipps' URI to their corresponding 'https' URI
forms [RFC2818] according to the rules in section 4.2 of this
document.
5.2. Applicability to IPP Printers
IPP Printers that implement this specification:
a) MUST support the IPP over HTTPS transport binding defined in
section 3.2 and the 'ipps' URI scheme defined in section 4;
b) MUST support the IPP over HTTP transport binding with TLS defined
in section 8.2 'Using IPP with TLS' of IPP/1.1 Encoding and
Transport [RFC2910] (for interoperability with existing IPP
implementations);
c) MUST only listen for incoming IPP protocol connections on
IANA-assigned well-known port 631 and MUST NOT listen for incoming
IPP protocol connections on any other port, unless explicitly
configured by system administrators or site policies;
d) MUST only generate 'ipps' URI used as protocol elements in
outgoing IPP protocol response messages that conform to the ABNF
specified in section 4.2 of this document (for example, in the
"job-uri" attribute in a 'Print-Job' response);
e) SHOULD only accept 'ipps' URI used as protocol elements in
incoming IPP protocol request messages that conform to the ABNF
specified in section 4.2 of this document (for example, in the
"printer-uri" operation attribute in a 'Print-Job' request);
f) SHOULD only generate 'ipps' URI for Jobs by appending exactly one
path component to the corresponding 'ipps' URI for the associated
Printer (for example, in the "job-uri" attribute in a 'Print-Job'
response);
g) SHOULD NOT generate 'ipps' URI that use literal IPv6 or IPv4
addresses (see section 4.2 for rationale).
McDonald, Sweet Expires 19 March 2014 [Page 12]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
6. IANA Considerations
IANA is asked to register 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 xxxx.
URI scheme semantics: The 'ipps' URI scheme is used to designate
secure IPP Printer objects (spoolers, application gateways, print
devices, etc.) on Internet hosts accessible using the IPP protocol
enhanced to support guaranteed data integrity and negotiable data
privacy using TLS [RFC5246] as specified in HTTP over TLS
[RFC2818].
Encoding Considerations: See section 4.3 of RFC xxxx.
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 protocol enhanced
to support guaranteed data integrity and negotiable data privacy
using TLS [RFC5246] as specified in HTTP over TLS [RFC2818]. Such
applications may include (but are not limited to) IPP-capable web
browsers, IPP Clients that wish to print a file, and servers (e.g.,
print spoolers) that wish to forward a print Job for processing.
Interoperability Considerations: A widely deployed IPP print
service CUPS (on most UNIX, Linux, and Mac OS X client systems) has
supported 'ipps' URI for several years. PWG IPP Everywhere
[PWG5100.14] (IPP secure, mobile printing extensions) requires the
use of 'ipps' URI for mandatory data integrity and optional data
confidentiality.
Security Considerations: See: Section 8 of RFC xxxx.
Contact:
Ira McDonald <blueroofmusic@gmail.com>
Michael Sweet <msweet@apple.com>
Author/Change controller:
IESG
McDonald, Sweet Expires 19 March 2014 [Page 13]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
References: RFC 2910, RFC 2911, and RFC xxxx.
[RFC Editor: Replace 'xxxx' with assigned RFC number before
publication]
7. Security Considerations
This 'ipps' URI Scheme specification adds the following additional
security considerations to those described in [RFC2910], [RFC2911],
[RFC2818], and [PWG5100.12]:
a) An 'ipps' URI might be faked to point to a rogue IPP secure print
service, thus collecting confidential document contents from IPP
Clients.
Server authentication mechanisms and security mechanisms specified
in IPP/1.1 Encoding and Transport [RFC2910], TLS/1.2 Protocol
[RFC5246], and HTTP over TLS [RFC2818] can be used to address this
threat.
b) An 'ipps' URI might be used to access an IPP secure print service
by an unauthorized IPP Client.
Client authentication mechanisms and security mechanisms specified
in IPP/1.1 Encoding and Transport [RFC2910], TLS/1.2 Protocol
[RFC5246], and HTTP over TLS [RFC2818] can be used to address this
threat.
c) 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.
d) 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 IPP
Model [RFC2911]).
Service discovery or directory protocols should be used to
discover the required IPP Client authentication mechanisms
associated with given 'ipps' URI.
See: Section 8 'Security Considerations' in [RFC2910].
See: Section 8 'Security Considerations' in [RFC2911].
McDonald, Sweet Expires 19 March 2014 [Page 14]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
See: Section 10 'Security Considerations' in [PWG5100.12].
See: Section 'Security Considerations' in [RFC2818].
See: Section 15 'Security Considerations' in [RFC2616].
See: Section 7 'Security Considerations' in [STD66].
8. References
8.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.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[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.
[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.
[RFC5246] Dierks, T., and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
McDonald, Sweet Expires 19 March 2014 [Page 15]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
[STD7] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[STD63] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, Uniform
Resource Identifiers (URI) Generic Syntax, STD 66, RFC
3986, January 2005.
[STD68] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
8.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.
[MIMEREG] Internet Assigned Numbers Authority (IANA) Registry "MIME
Media Types"
<http://www.iana.org/assignments/media-types/>
[PORTREG] Internet Assigned Numbers Authority (IANA) Registry "Port
Numbers"
<http://www.iana.org/assignments/port-numbers>
[RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179,
August 1990.
[RFC2569] Herriot, R., Ed., Hastings, T., Jacobs, N., and J.
Martin, "Mapping between LPD and IPP Protocols", RFC 2569,
April 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
[RFC3196] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H.
Holst, "Internet Printing Protocol/1.1: Implementor's
Guide", RFC 3196, November 2001.
[RFC3510] Herriot, R. and I. McDonald, "Internet Printing
Protocol/1.1: IPP URL Scheme", RFC 3510, April 2003.
McDonald, Sweet Expires 19 March 2014 [Page 16]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
9. Appendix A - Acknowledgments
This memo is published by IETF on behalf of 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.
Thanks to Tom Hastings (retired from Xerox), Bjoern Hoerhmann, Jerry
Thrasher (Lexmark), Mykyta Yevstifeyev, Pete Zehler (Xerox), and the
members of the PWG IPP WG.
The IPP URL Scheme [RFC3510] was the primary source for this
document.
10. Appendix B - Abbreviations Used in this Document
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 [RFC2616]
HTTPS - HTTP over TLS [RFC2818]
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>
McDonald, Sweet Expires 19 March 2014 [Page 17]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
RFC - Request for Comments
<http://www.rfc-editor.org/rfc.html>
TCP - Transmission Control Protocol [STD7]
TLS - Transport Layer Security [RFC5246]
URI - Uniform Resource Identifier [STD66]
URL - Uniform Resource Locator [STD66]
UTF-8 - Unicode Transformation Format - 8-bit [STD63]
11. Appendix X - Change History
[RFC Editor: Delete this section before publication as an RFC]
19 September 2013 - draft-mcdonald-ipps-uri-scheme-08.txt
Global - Updated references, per IPP WG review.
12 May 2013 - draft-mcdonald-ipps-uri-scheme-07.txt
Editorial - Revised section 1 (introduction) to add 'Rationale for
this document', per Smith Kennedy.
Editorial - Global - Changed 'Conformance Requirements' to
'Applicability', per Barry Leiba.
Editorial - Global - Changed '[PWG5100.EW]' to '[PWG5100.14]',
corrected date and URI, and moved section 8.1 (normative references),
per IPP WG review.
10 November 2012 - draft-mcdonald-ipps-uri-scheme-06.txt
Editorial - Global - Fixed typos and indentation, per IPP WG review.
Editorial - Global - changed 'generic drivers' to 'vendor-neutral
Client software', per IPP WG review.
Editorial - Revised section 8.2 (informative references, to correct
title of "PWG IPP Everywhere" (i.e., delete version number), per IPP
WG review.
14 May 2012 - draft-mcdonald-ipps-uri-scheme-05.txt
Editorial - Global - Fixed typos and indentation, per IPP WG review.
Editorial - Revised sections 3.1 and 3.2 (transport bindings) to
insert missing "to" in "connection to the target endpoint", per IPP
WG review.
Editorial - Revised section 4.2 (syntax), to correct indentation of
first "Note:", per IPP WG review.
Editorial - Revised sections 5.1 and 5.2 (client/printer conformance)
and section 7 (security considerations) to delete the out-of-scope
normative references to [RFC2817], per IPP WG review.
McDonald, Sweet Expires 19 March 2014 [Page 18]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
22 November 2011 - draft-mcdonald-ipps-uri-scheme-04.txt
Editorial - Global - Fixed typos and indentation, per IPP WG review.
Editorial - Revised Introduction and Acknowledgments to say 'project
for mobile, ubiquitous printing with generic drivers', per IPP WG
review.
Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add
references to HTTP POST and section 4 of RFC 2910, per IPP WG review.
Editorial - Revised sections 3.1 and 3.2 (transport bindings) to add
section references to all well-known standards (connection setup,
etc.), per IPP WG review.
Editorial - Revised section 4.2 (syntax) to move note from from
section 4.6 (examples) and explain why literal IP addresses should
NOT be used in 'ipps' URI, per IPP WG review.
Editorial - Revised sections 4.6.1 and 4.6.2 (examples) to replace
'abc.com' w/ 'example.com' (per IETF) and replace '/printer' path
element w/ '/ipp' (better practice), per IPP WG review.
Editorial - Revised section 5.2 (Printer conformance) to fold former
(c) and (d) into a single requirement for standard port 631 and
reordered other requirements to group MUSTs before SHOULDs, per IPP
WG review.
Editorial - Revised section 5.2 (Printer conformance) to add backward
reference to section 4.2 for rationale for not using IP literal
addresses, per IPP WG review.
Editorial - Revised section 6 (IANA) to explicitly state that 'ipps'
uses secure communications using HTTP over TLS, per IPP WG review.
Editorial - Revised section 7 (Security) to cleanup numerous loose
ends, per IPP WG review.
Editorial - Revised section 8 (References) to cleanup typos and
links, per IPP WG review.
Editorial - Revised section 1 (introduction), section 8.2
(informative references, and section 9 (appendix A) to change
"[IPPEVE]" to "[PWG5100.EW]", per IPP WG review.
26 August 2011 - draft-mcdonald-ipps-uri-scheme-03.txt
Editorial - Revised Abstract and Introduction to state published by
the IETF on behalf of IEEE-ISTO PWG (to avoid status ambiguity), per
Mykyta Yevstifeyev.
Editorial - Revised section 1 to list all currently defined versions
of IPP in RFC 2566, RFC 2911, and PWG 5100.12, per Mykyta
Yevstifeyev.
Technical - Revised section 1, section 2, section 3.2, section 4.1,
and section 7, to reference IPP Version 2.0 Second Edition (PWG
5100.12), per Mykyta Yevstifeyev.
Editorial - Revised section 3.1, to fix broken STD7 reference, per
Mykyta Yevstifeyev.
Editorial - Revised section 6, to add BCP35 reference for template
(regression loss when the template was moved up from former
appendix), per Mykyta Yevstifeyev.
Editorial - Revised section 8.1 to add PWG 5100.12 (normative),
McDonald, Sweet Expires 19 March 2014 [Page 19]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
Editorial - Revised section 8.2 to add PWG IPP Everywhere
(informative) and RFC 1179 (informative), per Mykyta Yevstifeyev.
Editorial - Revised appendix B to add references for more reading,
per Mykyta Yevstifeyev.
28 February 2011 - draft-mcdonald-ipps-uri-scheme-02.txt
Editorial - Revised document title to emphasize IPP over HTTPS
Transport Binding (reason for IETF standards-track status).
Editorial - Replaced "IPP URI" with "'ipp' URI", "IPPS URI" with
"'ipps' URI", "HTTP URI" with "'http' URI", and "HTTPS URI" with
"'https' URI" throughout this document for conformance to section 3.1
of [STD66], per Mykyta Yevstifeyev.
Editorial - Revised and simplified Abstract, per Mykyta Yevstifeyev.
Editorial - Revised and simplified section 1 'Introduction', per
Mykyta Yevstifeyev.
Editorial - Renamed section 2 from 'Conformance Terminology' to
'Conventions Used in this Document', per Mykyta Yevstifeyev.
Editorial - Moved former section 3.1 'IPP Model Terminology
(Normative)' content into section 2 'Conventions Used in this
Document' for readability, per Mykyta Yevstifeyev.
Editorial - Reordered subsections and reversed word order in all
subsection titles in section 4 'The 'ipps' URI Scheme' for
readability, per Mykyta Yevstifeyev.
Editorial - Added note to section 4.2 'Syntax of 'ipps' URI Scheme'
to explain why 'authority' production is NOT imported from [STD66],
because it includes an optional 'userinfo' component which cannot be
used in 'ipps' URI values.
Editorial - Deleted note describing empty 'host' component from
section 4.2 'Syntax of 'ipps' URI Scheme', because 'host' component
is mandatory in [STD66].
Editorial - Deleted 'Internationalization Considerations' section
which was redundant with section 4.3 'Character Encoding of 'ipps'
URI Scheme', per Mykyta Yevstifeyev.
Editorial - Revised all references to follow current RFC Editor
style, per Mykyta Yevstifeyev.
Editorial - Moved former 'Appendix A - Registration of IPPS URI
Scheme' content inline into section 6 'IANA Considerations', per
Mykyta Yevstifeyev.
Editorial - Moved former body section 'Acknowledgements' to 'Appendix
A - Acknowledgements', per Mykyta Yevstifeyev.
Editorial - Added new 'Appendix B - Abbreviations Used in this
Document' for readability, per Mykyta Yevstifeyev.
Editorial - Moved section 'Authors' Addresses' to end of document,
per Mykyta Yevstifeyev.
1 December 2010 - draft-mcdonald-ipps-uri-scheme-01.txt
- Technical - added UTF-8 [STD63] as required charset for all IPPS
URI in section 4.4 and section 7, per Bjoern Hoehrmann.
- Technical - corrected percent encoding for data octets outside the
US-ASCII range in section 4.4 and section 7, per Bjoern Hoehrmann.
McDonald, Sweet Expires 19 March 2014 [Page 20]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
- Editorial - global - changed "[RFC4395]" to "[BCP35]", changed
"[RFC3629]" to "[STD63]", changed "[RFC3986]" to "[STD66]", and
changed "[RFC5234]" to "[STD68]", per Bjoern Hoehrmann.
- Editorial - restored trailing "]]" in ABNF syntax in section 4.5,
per Bjoern Hoehrmann.
- Editorial - changed "Author/Change controller" to "IESG" in section
12 Appendix A registration template, as required by section 5.3 of
[BCP35], per Bjoern Hoehrmann.
10 October 2010 - draft-mcdonald-ipps-uri-scheme-00.txt
- Editorial - complete rewrite of RFC 3510 for new transport binding
- Editorial - moved Abstract to beginning of first page, per ID-Nits
- Editorial - fixed copyright, boilerplate, and typos, per ID-Nits
- Editorial - added references to RFCs 2119 and 3510, per ID-Nits
- Editorial - deleted obsolete references to RFCs 2246 and 4346, per
ID-Nits
- Technical - changed Intended Status to Standards Track to reflect
the new normative IPPS URI scheme and transport binding
- Technical - added section 3.2 IPP over HTTP Transport Binding
(informative)
- Technical - added section 3.3 IPP over HTTPS Transport Binding
(normative)
- Technical - updated section 5 Conformance Requirements to require
HTTP Upgrade (RFC 2817) support (for interoperability with existing
IPP implementations), per discussion on IPP WG mailing list
- Editorial - updated Appendix A w/ registration template from RFC
4395
12. Authors' Addresses
Ira McDonald
High North Inc
221 Ridge Ave
Grand Marais, MI 49839
Phone: +1 906-494-2434
Email: blueroofmusic@gmail.com
Michael Sweet
Apple Inc
10431 N De Anza Blvd, M/S 38-4LPT
Cupertino, CA 95014
Phone: +1 408-974-8798
Email: msweet@apple.com
McDonald, Sweet Expires 19 March 2014 [Page 21]
Internet Draft IPP over HTTPS and 'ipps' URI Scheme 19 Sept 2013
Usage questions and comments on this 'ipps' URI Scheme should be sent
directly to the editors at their above addresses and also to the PWG
IPP WG mailing list. Instructions for subscribing to the PWG IPP WG
mailing list can be found at:
PWG IPP WG Web Page: http://www.pwg.org/ipp/
PWG IPP WG Mailing List: ipp@pwg.org
PWG IPP WG Subscription: http://www.pwg.org/mailhelp.html
Implementers of this specification are encouraged to join the PWG IPP
WG Mailing List in order to participate in any discussions of
clarification issues and comments. Note that this IEEE-ISTO PWG
mailing list rejects mail from non-subscribers (in order to reduce
spam).
McDonald, Sweet Expires 19 March 2014 [Page 22]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/