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

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 <msweet@msweet.org> wrote:
> 
> Willem,
> 
>> On Jan 12, 2020, at 4:56 PM, Willem Groenewald via ipp <ipp@pwg.org> 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...
> 
>> Thinking out loud, a possible approach may be:
>> 	• 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
> 
> 
> 

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

Attachment: signature.asc