Subject: [IPP] Proper encoding to be used in "job-password" when "job-password-encryption" is not "none"

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Fri, 21 Apr 2017 17:28:37 +0000

Greetings,

Given the following scenario:
An IPP Printer has reported via Get-Printer-Attributes:
"job-password-supported" = 32
"job-password-encryption-supported" = 'none', 'md5'
(going to ignore "job-password-repertoire-configured" and "job-password-length-supported" for now...)
An IPP Client acquires from the User a job password "beeblebrox"

If the Client chooses 'none', then it should send in a Validate-Job operation

"job-password-encryption" = 'none'
"job-password" = 'beeblebrox'

However, if the Client chooses 'md5', how does it encode the md5 hash octets? Does it encode it as hex-ascii in 32 octets like so?

"job-password-encryption" = 'none'
"job-password" = '3f73fde3af41b6a50c84a75f84892b85'

Or since 'job-password' is defined in 5100.11 as "job-password (octetString(255))", is it reasonable for it to provide the raw binary value? I cannot find any statement in PWG 5100.11, RFC 8010, or wp-job-password-repertoire-20160101.pdf that makes this clear. Is the Printer expected to handle both scenarios?

Thoughts?

Smith

/**
    Smith Kennedy
    Wireless Architect - Client Software - IPG-PPS
    Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum / USB IF
    Chair, IEEE ISTO Printer Working Group
    HP Inc.
*/

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

---

From: Michael Sweet <[email-masked]>
Date: Fri, 21 Apr 2017 18:12:40 -0400

> Begin forwarded message:
> 
> From: Michael Sweet <[email-masked]>
> Subject: Re: [IPP] Proper encoding to be used in "job-password" when "job-password-encryption" is not "none"
> Date: April 21, 2017 at 6:12:20 PM EDT
> To: Smith Kennedy <[email-masked]>
> 
> Smith,
> 
> The octetString syntax is a BLOB type, so the raw MD5 bytes are transferred, not the ASCII representation.
> 
>> On Apr 21, 2017, at 1:28 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
>> 
>> Greetings,
>> 
>> 	• An IPP Printer has reported via Get-Printer-Attributes:
>> 		• "job-password-supported" = 32
>> 		• "job-password-encryption-supported" = 'none', 'md5'
>> 		• (going to ignore "job-password-repertoire-configured" and "job-password-length-supported" for now...)
>> 	• An IPP Client acquires from the User a job password "beeblebrox"
>> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Mon, 24 Apr 2017 19:40:52 +0000

Thanks Mike! So to put this all together:

RFC 8011 section 5.1.11 defines octetString as being simply a collection of octets
"job-password" is defined in PWG 5100.11 as "job-password (octetString(255))" which means its value will be raw octets
If "job-password-encryption" is "none" then there is no hashing, so presumably the plain octets are passed along (which is a bad security choice and also makes it possible for encoding confusion in the absence of "job-password-repertoire")
If "job-password-encryption" is one of the other keywords identifying a particular hashing algorithm, then the raw octets of the out put of that hashing algorithm are to be used.

Did I get that right?

Smith

> On Apr 21, 2017, at 4:12 PM, Michael Sweet <[email-masked]> wrote:
> 
> Smith,
>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 24 Apr 2017 16:04:54 -0400

Smith,

Yes, that is correct (although for plain-text job-password values are typically 4 to 6 digit PINs...)

> On Apr 24, 2017, at 3:40 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> 	• RFC 8011 section 5.1.11 defines octetString as being simply a collection of octets
> 	• "job-password" is defined in PWG 5100.11 as "job-password (octetString(255))" which means its value will be raw octets
> 	• If "job-password-encryption" is "none" then there is no hashing, so presumably the plain octets are passed along (which is a bad security choice and also makes it possible for encoding confusion in the absence of "job-password-repertoire")
> 	• If "job-password-encryption" is one of the other keywords identifying a particular hashing algorithm, then the raw octets of the out put of that hashing algorithm are to be used.
> 
> Did I get that right?
> 
> Smith
> 
> 
>