Subject: [IPP] Initial draft of IPPS URI Scheme (25 August 2010)

From: Ira McDonald <[email-masked]>
Date: Wed, 25 Aug 2010 14:53:23 -0400

Hi,

I've just posted an Initial draft of IPPS URI Scheme:

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-00-20100825.txt
  - plaintext Internet-Draft format (w/ explicit formfeeds)

  ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-00-20100825.htm
  - HTML w/ live table of contents

Hint:  You can view and print the plaintext file easily with
MS WordPad.

We agreed to do an IPP WG review first before submitting
this document to the IETF Internet-Drafts Editor.

This document was created by rewriting IPP URI Scheme
[RFC3510].

Comments?

Cheers,
- Ira (IPPS URI Scheme co-editor)

-----------------------------------------------------
Change Log

25 August 2010 - draft-mcdonald-ipps-uri-scheme-00.txt
- Editorial - complete rewrite of RFC 3510 for new transport binding
- Technical - added section 3.2 IPP over HTTP Transport Binding
- Technical - added section 3.3 IPP over HTTPS Transport Binding
- Editorial - updated Appendix A w/ registration template from RFC 4395

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "Zehler, Peter" <[email-masked]>
Date: Mon, 30 Aug 2010 05:35:27 -0700

Is it legal for two or more printer-uri-supported to differ only in the
URI scheme?

Peter Zehler

Xerox Research Center Webster
Email: [email-masked]
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ira
McDonald
Sent: Wednesday, August 25, 2010 2:53 PM
To: [email-masked]; Michael R Sweet; Ira McDonald
Subject: [IPP] Initial draft of IPPS URI Scheme (25 August 2010)

Hi,

ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-00-20100
825.txt
  - plaintext Internet-Draft format (w/ explicit formfeeds)

ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-00-20100
825.htm
  - HTML w/ live table of contents

Comments?

Cheers,

---

From: Ira McDonald <[email-masked]>
Date: Mon, 30 Aug 2010 11:20:56 -0400

Hi Pete,

Given RFC 2911 and RFC 3510 examples, I'd say that
2 or more printer-uri-supported values can legally differ
only by the URI scheme - I've seen printers that list both
"http:" (for IPP/1.0 compatibility) and "ipp:" (for IPP/1.1)
to the same target.

I think it's *unwise*.

But I don't think we can actually prohibit using both "ipp:"
(unsecured) and "ipps:" (TLS always) for the same IPP
Printer.

I do think we should RECOMMEND against the practice,
because it supplies ambiguous security to the IPP Printer
object.

I've urged all of my printer vendor clients to NOT allow
both unauthenticated (guest) and authenticated (with at
least HTTP Basic/Digest) access to the same instance
of IPP Printer object, because denial-of-service attacks
become much easier in this case.

All - your opinions?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

On Mon, Aug 30, 2010 at 8:35 AM, Zehler, Peter <[email-masked]>wrote:

> 825.txt<ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-00-20100%0A825.txt>
> 825.htm<ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-00-20100%0A825.htm>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 30 Aug 2010 14:34:08 -0700

On Aug 30, 2010, at 8:20 AM, Ira McDonald wrote:
> ...

FWIW, while it is certainly possible I think it would be better to simply require that printers supporting both ipp and ipps report the appropriate keywords for uri-security-supported (ssl3 and/or tls) along with mandatory support for HTTP Upgrade.  That would be consistent with our "message" since IPP/1.1 and gives us what we want on the standards side of things.

Whether a Printer allows clear-text connections when configured with SSL/TLS support is, IMHO, a site-specific policy outside the scope of IPP, and in particular HTTP Upgrade allows both the Client and Printer to enforce a particular policy dynamically.  Moreover, some communications channels may already be secured, making any transport-level encryption optional over those channels.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Ira McDonald <[email-masked]>
Date: Mon, 30 Aug 2010 17:41:54 -0400

Hi,

I agree with Mike.  If you support "ipps:" on an IPP Printer object
and also support "ipp:", then you MUST support HTTP Upgrade.

About encryption:

For many printing situations (emails, service messages, etc.) it's
fine to send the data in cleartext over the enterprise network, VPN,
or even public Internet - but you still want Data Integrity (i.e., secure
hashes of application PDUs in the TLS Record layer) - "print what
you sent" - right?

Cheers,
- Ira

On Mon, Aug 30, 2010 at 5:34 PM, Michael Sweet <[email-masked]> wrote:

> FWIW, while it is certainly possible I think it would be better to simply
> require that printers supporting both ipp and ipps report the appropriate
> keywords for uri-security-supported (ssl3 and/or tls) along with mandatory
> support for HTTP Upgrade.  That would be consistent with our "message" since
> IPP/1.1 and gives us what we want on the standards side of things.
>
> Whether a Printer allows clear-text connections when configured with
> SSL/TLS support is, IMHO, a site-specific policy outside the scope of IPP,
> and in particular HTTP Upgrade allows both the Client and Printer to enforce
> a particular policy dynamically.  Moreover, some communications channels may
> already be secured, making any transport-level encryption optional over
> those channels.
>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 30 Aug 2010 16:43:51 -0700

> hashes of application PDUs in the TLS Record layer) - "print what

In general, data injection/replacement isn't a real problem - aside from pranks, there is little to be gained at great cost, especially when most jobs are one-offs.

The real issues for secure printing environments are privacy/disclosure of print data and authentication and authorization of clients, servers, and services.  For example, when you print something on the MFD down the hall, are you actually talking to the MFD down the hall when you send the print job?  TLS provides a way to provide both privacy and authentication/authorization, but for environments where the network is already secured something as simple as Digest authentication with the MD5-session stuff may be sufficient to prevent man-in-the-middle attacks.