Subject: Re: [IPP] IPP Enterprise Printing Extensions: Feature Names and Job Types

From: Willem Groenewald via ipp <[email-masked]>
Date: Mon, 6 Jan 2020 10:36:22 +1100

Hi Smith

Apologies for the delay, just returned from leave.

Here are a few comments on the naming (probably more "thoughts" to spark
some thinking):

1) The use-cases and flows around "Password Protected Job" and "User
Credential Protected Job" are very similar.  The names should be related.
 e.g. both are "release" and path "protect" the job.  It's the means of
protection that are changing.  Hence we'd recommend having very similar
names.  If you're keen to add the word "release", we'd suggest making sure
this also exists on the password protected job too.

2) We've taken a look at the draft of the Enterprise Printing Extensions
v2.0 w.r.t these mentioned features, and would love an opportunity to dive
a little deeper around security. Some immediate thoughts from a quick look,
that may or may not have been considerer, are:

   - The use of hashing methods that are no longer considered "secure".
   Would it make sense for a standard released in 2020 include these as
   options?
   - Requiring these features to be available over TLS connections
   - Have downgrade (or reply) attacks been considered?

Cheers,

Chris & Bez in the PaperCut Dev Team (plus now Willem)

On Thu, 19 Dec 2019 at 04:12, Kennedy, Smith (Wireless & IPP Standards) via
ipp <[email-masked]> wrote:

> Hi there,
>
> I'm in the process of producing a new draft of IPP Enterprise Printing
> Extensions v2.0 (EPX) and I'm trying to nail down the "feature names" and
> "job types" for the several features defined therein.
>
> What I have thus far is this:
>
> Job Password
>         • Feature: Password Job Protection
>         • Job Type: Password Protected Job
>         • Use Case: Protecting a Job with a Password
>
> Job Storage
>         • Feature: Job Storage
>         • Job Type: Stored Job
>         • Use Case: Storing a Job for Later Reprinting, Reprinting a
> Stored Job
>
> Proof Print
>         • Feature: Proof Print
>         • Job Type: Proof Job
>         • Use Case: Proof Printing
>
> Authenticated Release
>         • Feature: Authenticated Release? Credential Job Protection?
>         • Job Type: User Credential Protected Job?
>         • Use Case: Protecting a Job with User Authentication Credentials
>
> Any feedback on any of these labels? Thanks for any help!
>
> Smith
>
> /**
>     Smith Kennedy
>     HP Inc.
> */
>
> _______________________________________________
> ipp mailing list
> [email-masked]
> https://www.pwg.org/mailman/listinfo/ipp
>

-- 
*Willem Groenewald*
Product Owner
<http://www.papercut.com/>
mob:  +61 439 584 646
web:    www.papercut.com

<https://twitter.com/papercutdev>   <https://facebook.com/papercutsoftware>
   <http://www.linkedin.com/company/papercut-software>
<https://google.com/+PaperCutSoftware>
<https://youtube.com/papercutsoftware>

Please consider the environment before printing this email... or install
PaperCut and let it do the considering for you!
_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Mon, 6 Jan 2020 19:32:26 +0000

Hi Willem,

Thanks for the feedback! Replies below.

Smith

/**
    Smith Kennedy
    HP Inc.
*/

> On Jan 5, 2020, at 4:36 PM, Willem Groenewald <[email-masked]> wrote:
> 
> Hi Smith
> 
> Here are a few comments on the naming (probably more "thoughts" to spark some thinking):
> 
> 1) The use-cases and flows around "Password Protected Job" and "User Credential Protected Job" are very similar.  The names should be related.  e.g. both are "release" and path "protect" the job.  It's the means of protection that are changing.  Hence we'd recommend having very similar names.  If you're keen to add the word "release", we'd suggest making sure this also exists on the password protected job too.

Mike Sweet earlier responded with a similar suggestion that I name them "Release Printing", so I'm going to go with that in the next revision, that I'm working on currently.

> 
> 2) We've taken a look at the draft of the Enterprise Printing Extensions v2.0 w.r.t these mentioned features, and would love an opportunity to dive a little deeper around security. Some immediate thoughts from a quick look, that may or may not have been considerer, are:
> The use of hashing methods that are no longer considered "secure".  Would it make sense for a standard released in 2020 include these as options?
> Requiring these features to be available over TLS connections
> Have downgrade (or reply) attacks been considered?
These are all very good questions, but require some explanation. Let's see how I do here and if you have more questions, we can continue to discuss.

This IPP Enterprise Printing Extensions v2.0 is a v2.0 because it is a refactoring and renaming of the PWG 5100.11-2010 (IPP Job and Printing Extensions - Set 2 (JPS2)) specification that dates to 2010.

The "job-password" and "job-password-encryption" attributes originated in that spec. When I worked on adding the "job-password-repertoire" registration in 2015, that registration deprecated a number of the "job-password-encryption" methods and added newer ones. We deprecated MD2, MD4, MD5 and SHA1. In the PWG, "deprecated" means that Printers SHOULD NOT support them, and operators SHOULD NOT use them if they are supported by one of their printers. We have yet to obsolete them out of concern for backward compatibility, but it has now been 4 years. If you are suggesting that we obsolete these in IPP Enterprise Printing Extensions v2.0, I think we should consider it in the IPP WG. Are there others you think should be deprecated or added?

I don't think we can require TLS when "job-password" is used without breaking backward compatibility. I personally think TLS ought to be required by all Printers deployed in the field. Some of this comes down to a delta between conformance requirements and deployment policy.

When you ask about downgrade or replay attacks (you meant "replay", not "reply", right?), can you be more specific about your concerns?

> On Thu, 19 Dec 2019 at 04:12, Kennedy, Smith (Wireless & IPP Standards) via ipp <[email-masked] <mailto:[email-masked]>> wrote:
> Hi there,
> 
> I'm in the process of producing a new draft of IPP Enterprise Printing Extensions v2.0 (EPX) and I'm trying to nail down the "feature names" and "job types" for the several features defined therein.
> 
>         • Use Case: Storing a Job for Later Reprinting, Reprinting a Stored Job
> 
> Proof Print
>         • Feature: Proof Print
>         • Job Type: Proof Job
> [email-masked] <mailto:[email-masked]>
> https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
> 
> 
> --
> Willem Groenewald
> Product Owner
> web:    www.papercut.com <http://www.papercut.com/>
> 
>  <https://twitter.com/papercutdev>   <https://facebook.com/papercutsoftware>   <http://www.linkedin.com/company/papercut-software>   <https://google.com/+PaperCutSoftware>   <https://youtube.com/papercutsoftware>
> 
> Please consider the environment before printing this email... or install PaperCut and let it do the considering for you!

---

From: Willem Groenewald via ipp <[email-masked]>
Date: Mon, 13 Jan 2020 08:56:34 +1100

Hi Smith,

*1) Use case and naming*
Thanks for confirming the name consideration. That's great.

*2) Password protected jobs*
Our concerns here can probably be best explained by a hypothetical use-case:

*Alice works with Bob and is concerned that he may be doing
something naughty and is scheming with *Carol *via Twitter DM messages.
She successfully uses an ARP poisoning attack on their local LAN and starts
intercepting Bob's network traffic.  She quickly learns that Twitter's TLS
configuration is A+ and is too hard to decipher.  Instead she needs to find
a weaker link.  After a quick nmap scan Alice stumbles upon her perfect
vector - the printer in the corner of the office!  It has a self-signed TLS
cert, and implements a password hashing strategy designed somewhere in the
early 90's. Sure. She could hack Bob's printing with her new MITM powers...
but that's not valuable - It's the password that she wants. Alice knows
that Bob is not too computer savvy and is likely to use the same password
on his print jobs as he does from his Twitter account (and probably other
accounts too!).  Later that day Bob goes to print two movie tickets to see
Star Wars, and Alice is waiting with wireshark in hand. There it is!
The IPP attribute job-password is 482c811da5d5b4bc6d497ffa98491e38 .  It's
MD5 and is not a salted, nor HMAC'ed.  She quickly consults her local
rainbow table and bingo!*

Our concerns are that the standard does not call for TLS, does not require
TLS identity validation, and uses a message digest as opposed to a HMAC or
salted hash.  We feel more protection is required because of the "human
factor": The "password" is often more valuable that the contents of the
print job itself.

As a point of reference even RFC2069 back in 1997 has a server supplied
nonce used as a salt.

Thinking out loud, a possible approach may be:

   1. Pass a nonce to client in the Create-Job response
   2. Require the client to use the nonce (and possible other attributes
   such as interactions and output length) to derive
   3. Consider rfc2898 or equivalent

A 2nd option might be to simply drop all references to hashing and require
passwords to be in plain text. That way implementers are not lulled into a
false sense of security and know their only option is to ensure all traffic
is encapsulated in TLS.  We are aware of the need for backwards
compatibility and do support this.  We have noticed that some clients in
the field already require TLS.  For example iOS or Mac device have taken
such a step: If an IPP printer requires authentication but does not support
TLS, the client ignore authentication request and does not prompt user with
a user/password dialog.  We feel this is a good strategy and would like to
see any new parts of the standard build upon best practice security today,
rather than build upon the older approaches already in other parts.

*Downgrade Attack*
If the intention of having a repertoire is solely to improve client/printer
compatibility, and we assume all "encryption methods" are equal for our use
case, then this should be fine.  If however, the intent is to also support
future evolving crypto standards then it's an issue.  The only sure fire
way to prevent downgrade attacks to remove backwards compatibility.  Again,
another vote for TLS encapsulation - leave all this up to the TLS group
instead :-) Another option which would mitigate risk might be to recommend
that clients "pin" what it sees as the "best option".  That way a downgrade
attack is at least limited to the first request only.

*Reply Attacks*
Yes. Sorry about the spello. We did mean "replay".  One thought experiment
was, what if an attacker replay a near identical job substituting the print
job content (e.g. A financial report with fudged data).  Could you trick
this person into thinking it was their job because it was released with
their secret password no one else should know?  Again a per job printer
supplied nonce may prevent this, or of course TLS which is immune to replay
by design.

Another thought: Acknowledging we haven't looked too deeply here to see if
it's possible, but seeing a lot of reference to "stored jobs and reprinted"
raised this thought.  e.g.

   - The hashed password is collected via MITM from a previous request
   (assume good hashing so it's not reversible)
   - The job can be started from an IPP command (e.g. a reprint command,
   and not just the panel)
   - The same hashed job-password attribute is replayed into this command
   to start the job

I hope this adds some food for thought.  Security is hard.  We often
measure our design sessions by "number of coffees" and security design
often leads to sleepless night due to both the risks and the shear coffee
consumed :-)

Cheers,

Chris, Bez & Williem in the PaperCut Dev Team

On Tue, 7 Jan 2020 at 06:32, Kennedy, Smith (Wireless & IPP Standards) <
[email-masked]> wrote:

> Mike Sweet earlier responded with a similar suggestion that I name them
> "Release Printing", so I'm going to go with that in the next revision, that
> I'm working on currently.
>
>
> These are all very good questions, but require some explanation. Let's see
> how I do here and if you have more questions, we can continue to discuss.
>
> This IPP Enterprise Printing Extensions v2.0 is a v2.0 because it is a
> refactoring and renaming of the PWG 5100.11-2010 (IPP Job and Printing
> Extensions - Set 2 (JPS2)) specification that dates to 2010.
>
> The "job-password" and "job-password-encryption" attributes originated in
> that spec. When I worked on adding the "job-password-repertoire"
> registration in 2015, that registration deprecated a number of the
> "job-password-encryption" methods and added newer ones. We deprecated MD2,
> MD4, MD5 and SHA1. In the PWG, "deprecated" means that Printers SHOULD NOT
> support them, and operators SHOULD NOT use them if they are supported by
> one of their printers. We have yet to obsolete them out of concern for
> backward compatibility, but it has now been 4 years. If you are suggesting
> that we obsolete these in IPP Enterprise Printing Extensions v2.0, I think
> we should consider it in the IPP WG. Are there others you think should be
> deprecated or added?
>
> I don't think we can require TLS when "job-password" is used without
> breaking backward compatibility. I personally think TLS ought to be
> required by all Printers deployed in the field. Some of this comes down to
> a delta between conformance requirements and deployment policy.
>
> When you ask about downgrade or replay attacks (you meant "replay", not
> "reply", right?), can you be more specific about your concerns?
>
>
> Cheers,
>
> On Thu, 19 Dec 2019 at 04:12, Kennedy, Smith (Wireless & IPP Standards)
> via ipp <[email-masked]> wrote:
>
>> Hi there,
>>

---

From: Michael Sweet via ipp <[email-masked]>
Date: Mon, 13 Jan 2020 23:17:08 -0500

Willem,

> On Jan 12, 2020, at 4:56 PM, Willem Groenewald via ipp <[email-masked]> wrote:
> ...
> Our concerns are that the standard does not call for TLS, does not require TLS identity validation, and uses a message digest as opposed to a HMAC or salted hash.  We feel more protection is required because of the "human factor": The "password" is often more valuable that the contents of the print job itself.

OK, so there are several concerns here:

1. TLS with self-signed certificates; while we currently do not have a standalone document with TLS best-practices, IPP/1.1 (STD 92 aka RFC 8010 & 8011) does reference the IETF's TLS best practices which has a few things to say about certificate validation policies...  So long as the Client implements validation policies (TOFU is common for IoT devices right now) self-signed can IMHO be just as secure as CA-signed.

2. job-password hashes are not salted and historically have been 4-6 digit PINs (not alphanumeric passwords) making them a poor substitute for proper authentication.  We've expanded on this over the years (particularly with the job-password-repertoire stuff) and had some discussion about requiring TLS when transmitting job-password (and FWIW CUPS forces a TLS upgrade in these cases), but from a security standpoint nobody should trust job-password for authentication at the device, regardless of the repertoire or TLS usage.

3. Some Client implementations (iOS in particular) generate a random PIN (a OTP) for the user when job-password is required for printing.  The End User can then go to the printer, enter the PIN that they see on their mobile device, and collect the printout.  This eliminates the "human factor" when selecting a job-password value but not the weakness in job-password hashing...

I will also note that my Encrypted Jobs and Documents specification is intended to provide "real" end-to-end security and authentication, but that is overkill for 99.999999% of all printing - the purpose of PIN and release printing is to eliminate waste printing where the user prints something and forgets to pick it up at the printer so paper/toner/ink is wasted.  Protecting the PIN is important to prevent the job from being picked up by the wrong user, but the primary goal is to eliminate waste printing.

If you want security, then you use physical authentication - an ID card, NFC, etc. - that is tied to the authenticated user information associated with each print job.

> As a point of reference even RFC2069 back in 1997 has a server supplied nonce used as a salt.

and had all sorts of weaknesses that got "corrected" in RFC 2617 and later RFC 7616.  And still the IETF doesn't recommend the use of Digest auth...

> 	• Pass a nonce to client in the Create-Job response

Breaks existing clients...

> 	• Require the client to use the nonce (and possible other attributes such as interactions and output length) to derive

but job-password is an operation attribute for Create-Job, so at that point you've already sent the value.

> 	• Consider rfc2898 or equivalent

That is the focus of the Encrypted Jobs and Documents spec, which depends on PGP because S/MIME is broken (no replacement for CBC mode).

> A 2nd option might be to simply drop all references to hashing and require passwords to be in plain text. That way implementers are not lulled into a false sense of security and know their only option is to ensure all traffic is encapsulated in TLS.  We are aware of the need for backwards compatibility and do support this.  We have noticed that some clients in the field already require TLS.  For example iOS or Mac device have taken such a step: If an IPP printer requires authentication but does not support TLS, the client ignore authentication request and does not prompt user with a user/password dialog.  We feel this is a good strategy and would like to see any new parts of the standard build upon best practice security today, rather than build upon the older approaches already in other parts.

I'm actually OK with deprecating "job-password-encryption" since I 100% agree that it provides a false sense of security.

> ...
> Reply Attacks
> Yes. Sorry about the spello. We did mean "replay".  One thought experiment was, what if an attacker replay a near identical job substituting the print job content (e.g. A financial report with fudged data).  Could you trick this person into thinking it was their job because it was released with their secret password no one else should know?  Again a per job printer supplied nonce may prevent this, or of course TLS which is immune to replay by design.

That's one advantage of TLS + a random PIN - hard to spoof jobs like that.

Certainly we can include this as one potential attack in the security considerations, but it is very hard to defend against insiders... (but again look at Encrypted Jobs and Documents...)

________________________
Michael Sweet

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Tue, 14 Jan 2020 19:03:47 +0000

Thanks Mike for answering Willem's questions! We can document some of the practices use by iOS and provide those in IPP Enterprise Printing Extensions v2.0 as implementation recommendations.

Willem, in addition to Mike's responses, I also wanted to point out that doing "Job Release" with user credentials as defined in this new IPP Enterprise Printing Extensions v2.0 specification means one less password as well as hopefully using both TLS and a better method of passing a password, though it requires infrastructure to create and maintain the user accounts.

Smith

/**
   Smith Kennedy
   HP Inc.
*/

> On Jan 13, 2020, at 9:17 PM, Michael Sweet <[email-masked]> wrote:
> 
> Willem,
>