attachment
<div dir="ltr"><div>Hi Smith,</div><div><br></div><div><b>1) Use case and naming</b></div><div>Thanks for confirming the name consideration. That's great.</div><div><br></div><div><b>2) Password protected jobs</b></div><div>Our concerns here can probably be best explained by a hypothetical use-case:</div><div><br></div><div><i>Alice works with Bob and is concerned that he may be doing something naughty and is scheming with </i>Carol<i> </i><i>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!</i></div><div><br></div><div>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.</div><div><br></div><div>As a point of reference even RFC2069 back in 1997 has a server supplied nonce used as a salt.</div><div><br></div><div>Thinking out loud, a possible approach may be:</div><div><ol><li style="margin-left:15px">Pass a nonce to client in the Create-Job response</li><li style="margin-left:15px">Require the client to use the nonce (and possible other attributes such as interactions and output length) to derive</li><li style="margin-left:15px">Consider rfc2898 or equivalent</li></ol><div>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.</div></div><div><br></div><div><b>Downgrade Attack</b></div><div>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.</div><div><br></div><div><b>Reply Attacks</b></div><div>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.</div><div><br></div><div>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. </div><div><ul><li style="margin-left:15px">The hashed password is collected via MITM from a previous request (assume good hashing so it's not reversible)</li><li style="margin-left:15px">The job can be started from an IPP command (e.g. a reprint command, and not just the panel)</li><li style="margin-left:15px">The same hashed job-password attribute is replayed into this command to start the job</li></ul></div><div><br></div><div>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 :-)</div><div><br></div><div>Cheers,</div><div><br></div><div>Chris, Bez & Williem in the PaperCut Dev Team</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 7 Jan 2020 at 06:32, Kennedy, Smith (Wireless & IPP Standards) <<a href="mailto:smith.kennedy@hp.com">smith.kennedy@hp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Hi Willem,<div><br></div><div>Thanks for the feedback! Replies below. </div><div><br><div>
Smith<br><br>/**<br> Smith Kennedy<br> HP Inc.<br>*/
</div>
<div><br><blockquote type="cite"><div>On Jan 5, 2020, at 4:36 PM, Willem Groenewald <<a href="mailto:willem.groenewald@papercut.com" target="_blank">willem.groenewald@papercut.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr">Hi Smith<div><br></div><div>Apologies for the delay, just returned from leave.</div><div><br></div><div>Here are a few comments on the naming (probably more "thoughts" to spark some thinking):<br><br>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.<br></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div dir="ltr"><div><br>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:<br><ul><li>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?</li><li>Requiring these features to be available over TLS connections</li><li>Have downgrade (or reply) attacks been considered?</li></ul></div></div></div></div></blockquote><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>When you ask about downgrade or replay attacks (you meant "replay", not "reply", right?), can you be more specific about your concerns?</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div dir="ltr"><div>Cheers,<br><br>Chris & Bez in the PaperCut Dev Team (plus now Willem)<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 19 Dec 2019 at 04:12, Kennedy, Smith (Wireless & IPP Standards) via ipp <<a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi there,<br>
<br>
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.<br>
<br>
What I have thus far is this:<br>
<br>
Job Password<br>
• Feature: Password Job Protection<br>
• Job Type: Password Protected Job<br>
• Use Case: Protecting a Job with a Password<br>
<br>
Job Storage<br>
• Feature: Job Storage<br>
• Job Type: Stored Job<br>
• Use Case: Storing a Job for Later Reprinting, Reprinting a Stored Job<br>
<br>
Proof Print<br>
• Feature: Proof Print<br>
• Job Type: Proof Job<br>
• Use Case: Proof Printing<br>
<br>
Authenticated Release<br>
• Feature: Authenticated Release? Credential Job Protection?<br>
• Job Type: User Credential Protected Job?<br>
• Use Case: Protecting a Job with User Authentication Credentials<br>
<br>
Any feedback on any of these labels? Thanks for any help!<br>
<br>
Smith<br>
<br>
/**<br>
Smith Kennedy<br>
HP Inc.<br>
*/<br>
<br>
_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp" rel="noreferrer" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div style="color:rgb(136,136,136);font-size:12.8px"><div style="font-size:12.8px"><font color="#6aa84f" face="tahoma, sans-serif" size="2"><b>Willem Groenewald</b></font></div><div style="font-size:12.8px"><font face="tahoma, sans-serif" size="1">Product Owner</font></div></div><div style="color:rgb(136,136,136);font-size:12.8px"><font size="1"><a href="http://www.papercut.com/" style="color:rgb(17,85,204)" target="_blank"><img alt="" src="http://cdn.papercut.com/files/email/papercut.png"></a><br></font></div><div style="color:rgb(136,136,136);font-size:12.8px"><span style="font-size:x-small">mob: +61 439 584 646</span><br></div><div style="color:rgb(136,136,136);font-size:12.8px"><font size="1">web: <span style="color:rgb(61,133,198)"><a href="http://www.papercut.com/" style="color:rgb(17,85,204)" target="_blank">www.papercut.com</a></span><br></font></div><div style="color:rgb(136,136,136);font-size:12.8px"><br></div><div dir="ltr" style="color:rgb(136,136,136);font-size:12.8px"><a href="https://twitter.com/papercutdev" style="color:rgb(17,85,204)" target="_blank"><img alt="" src="http://cdn.papercut.com/files/email/twitter-grey.png"></a> <a href="https://facebook.com/papercutsoftware" style="color:rgb(17,85,204)" target="_blank"><img alt="" src="http://cdn.papercut.com/files/email/facebook-grey.png"></a> <a href="http://www.linkedin.com/company/papercut-software" style="color:rgb(17,85,204)" target="_blank"><img alt="" src="http://cdn.papercut.com/files/email/linkedin-grey.png"></a> <a href="https://google.com/+PaperCutSoftware" style="color:rgb(17,85,204)" target="_blank"><img src="http://cdn.papercut.com/files/email/google-plus-grey.png"></a> <a href="https://youtube.com/papercutsoftware" style="color:rgb(17,85,204)" target="_blank"><img alt="" src="http://cdn.papercut.com/files/email/youtube-grey.png"></a><br><font color="#cccccc" size="1"><br>Please consider the environment before printing this email... or install PaperCut and let it do the considering for you!</font></div></div></div></div></div>
</div>
</div></blockquote></div><br></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="color:rgb(136,136,136);font-size:12.8px"><div style="font-size:12.8px"><font color="#6aa84f" face="tahoma, sans-serif" size="2"><b>Willem Groenewald</b></font></div><div style="font-size:12.8px"><font face="tahoma, sans-serif" size="1">Product Owner</font></div></div><div style="color:rgb(136,136,136);font-size:12.8px"><font size="1"><a href="http://www.papercut.com/" style="color:rgb(17,85,204)" target="_blank"><img alt="" src="http://cdn.papercut.com/files/email/papercut.png"></a><br></font></div><div style="color:rgb(136,136,136);font-size:12.8px"><span style="font-size:x-small">mob: +61 439 584 646</span><br></div><div style="color:rgb(136,136,136);font-size:12.8px"><font size="1">web: <span style="color:rgb(61,133,198)"><a href="http://www.papercut.com/" style="color:rgb(17,85,204)" target="_blank">www.papercut.com</a></span><br></font></div><div style="color:rgb(136,136,136);font-size:12.8px"><br></div><div dir="ltr" style="color:rgb(136,136,136);font-size:12.8px"><a href="https://twitter.com/papercutdev" style="color:rgb(17,85,204)" target="_blank"><img alt="" src="http://cdn.papercut.com/files/email/twitter-grey.png"></a> <a href="https://facebook.com/papercutsoftware" style="color:rgb(17,85,204)" target="_blank"><img alt="" src="http://cdn.papercut.com/files/email/facebook-grey.png"></a> <a href="http://www.linkedin.com/company/papercut-software" style="color:rgb(17,85,204)" target="_blank"><img alt="" src="http://cdn.papercut.com/files/email/linkedin-grey.png"></a> <a href="https://google.com/+PaperCutSoftware" style="color:rgb(17,85,204)" target="_blank"><img src="http://cdn.papercut.com/files/email/google-plus-grey.png"></a> <a href="https://youtube.com/papercutsoftware" style="color:rgb(17,85,204)" target="_blank"><img alt="" src="http://cdn.papercut.com/files/email/youtube-grey.png"></a><br><font color="#cccccc" size="1"><br>Please consider the environment before printing this email... or install PaperCut and let it do the considering for you!</font></div></div></div></div></div>