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) <
smith.kennedy at hp.com> wrote:
> Hi Willem,
>> Thanks for the feedback! Replies below.
>> Smith
>> /**
> Smith Kennedy
> HP Inc.
> */
>> On Jan 5, 2020, at 4:36 PM, Willem Groenewald <
>willem.groenewald at papercut.com> wrote:
>> 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.
>>> 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?
>>> 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 <ipp at pwg.org> 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
>>ipp at pwg.org>>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!
>>>
--
*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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20200113/ff2a8d47/attachment.html>