Last Call Review of draft-mcdonald-ipps-uri-scheme-15
review-mcdonald-ipps-uri-scheme-15-secdir-lc-murphy-2014-12-11-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  Document
editors and WG chairs should treat these comments just like any other last call
comments.

This document proposes a new ipps: URI for secure IPP protocol use.

The security considerations section of this document seems quite thorough (and
adds considerably to the original IPP documents series - 2910, 2911, 2567, etc.)

The authors should be complimented on the document clarity and structure.

Some comments below.

-Sandy

Section 1

   This document updates [RFC2910] and [RFC2911].

   This document updates:

It is easy to see that this documents covers topics in the sections
listed, but not clear what the "update" is exactly.  For example:

   b) IPP/1.1 Model and Semantics [RFC2911], by extending section 4.1.6
      'uriScheme' and section 4.4.1 'printer-uri-supported'; and

RFC2911 section 4.1.6 lists some "Standard values for this syntax
type" for the uriScheme attibute - is it intended that this document
add ipps: to that list?  That would seem logical but is not explictly
stated.

section 4.2

   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.
...
   Per PWG IPP Everywhere [PWG5100.14], for compatibility with existing
   IPP implementations, IPP Printers SHOULD NOT generate (or allow
   administrators to configure) URI lengths above 255 octets, because
   many older IPP Client implementations do not properly support these
   lengths.

Is this a concern for ipps in particular, or would it apply to ipp as
well?  (Is this one of the updates to RFC2911/RFC2910?)

section 6.2.4

   Either service discovery or directory protocols SHOULD be used first
   or an IPP Client SHOULD first establish an 'ipp' connection (without
   TLS [RFC5246] or any client authentication) to the target IPP Printer
   and use a Get-Printer-Attributes operation to discover the required
   IPP Client authentication mechanism(s) associated with a given 'ipps'
   URI.

I am not sure what the client would do with the information of the
Client Authentication types before it attempted the ipps connection,
but retrieving that information with no protection seems dangerous.
At least, should the unprotected request be limited to mention the
ipps URI as the target and request only the
uri-authentication-supported attribute?  To at least limit the
possibility that the response will include all attributes and the
client will accept them before attempting the ipps connection?

The following is a discussion of the potential for a tiered network of Printer
Objects.

This document talks about "a downstream IPP printer" and "print
gateway" and defines an IPP Printer as something that can receive
operations from an "upstream" client or printer.

I was curious as to whether the protocol is intended to be used in a
hierarchy.

Looking at other parts of the IPP document set:

RFC2911 talks about possible "n-tier" client/server systems (sec 1.1),
a client as a print server that sends requests to "another
"downstream" print server." (sec 2.1) "Forwarding Servers" as a
"gateway to a printing system" (sec 4.3.7.1), forwarding to a print
system (sec 4.3.8), etc.  RFC3196 talks about "forward received jobs
(and other requests) to other devices and print servers/services" (sec
2).  PWG 5100.14 (IPP Everywhere) speaks of a Printer as possibly
representing a Logical Device which might forward the job (sec 2.2),
and Indirect Imaging as "an intermediary service in a different
administrative domain" (sec 2.3).

The IPP protocol itself provides no mechanism to represent or create
such interactions.  But each Printer object can "turn around" and open
a new IPP exchange, to accomplish the job it had received, and the
originator will not be aware.  And of course each intermediate service
also has the opportunity to modify the job - change the attributes (eg
copies) or even for an inline document to modify what is printed.
There is also no way to know that the new IPP exchange used ipps.

Perhaps this is just a standard part of any use of http - you never
know whether the end site is employing other sites to provide the
service.  But since this seems to be part of the envisioned use case,
not just an implementation device, it seems proper to consider the
security in such circumstances.

RFC2911 section 8.1.3, for example, notes that a document that is a
reference to a URI:

                       the print request can contain a reference, or
   pointer, to the document instead of the actual document itself (see
   sections 3.2.2 and 3.3.2). Standard methods currently do not exist
   for remote entities to "assume" the credentials of a client for
   forwarding requests to a 3rd party. It is anticipated that Print-By-
   Reference will be used to access "public" documents and that
   sophisticated methods for authenticating "proxies" is not specified
   in this document.

Perhaps a similar thought applies to a tiered print service.  Logical
Devices, forwarding of job requests, printer objects that speak IPP to
other printer objects, are anticipated to be used in environments
where the client places complete trust in the print service or Printer
object that it contacts and recursively any other services it might
employ.  Methods for authenticating Prineter objects, print services,
etc, "downstream" of the Printer Object contacted by ipps are not
specified.

Attachment:

signature.asc

Description:

 Message signed with OpenPGP using GPGMail