Waking this up again, and bringing it back to the IPP reflector.
I didn't think about the print server case, where one host is hosting multiple printers. That brings us all the way back to submitting the URI, which provides both the host name and the resource path of the printer.
I still suspect that, even for the "standard" printer, it is necessary for the Client to supply the Printer's certificate fingerprint so that the Authentication Service can confirm that the Client is interacting with a particular Printer hosted on a system that is using a TLS certificate that has a particular fingerprint. If it doesn't want to use it, it can ignore it. But it should know the current certificate fingerprint, right?
Smith
> On Dec 7, 2022, at 1:50 AM, Piotr Pawliczek <pawliczek at google.com> wrote:
>> CAUTION: External Email
>> Hi Smith,
>>>>>>> The problem with printers is that users do not verify their URLs like they do when browsing the internet. So, the Authorization Server must do it. This is why we have to send to the AS the priner's URL locked by its certificate.
>>>> I'm not sure I agree with that entirely but for print server hosted printer URLs, whether on-premises or in the cloud, that is certainly true.
>>>>> Another problem is that a client can access multiple printers with different URLs managed by the same AS, which does not fit into "standard" OAuth2/OpenID use cases. With the standard approach, the client should ask the user about each printer separately.
>>>> I'm not sure that I follow you here. Are you suggesting that if printing was following the more conventional OAuth 2.0 or OIDC use cases, each printer would have its own Authentication Service?
>> In our case a printer is like a resource server in OAuth terminology. In the "standard" OAuth use case the client knows the resource server. In our case it is not true. The client somehow discovers/queries printers from the environment, their URLs are not hard coded inside the client.
>>>>> Agree in general any static value provided by an IPP attribute is unsound - it can be scooped up by anybody and presented as its own.
>>>> Although an X.509 certificate is arguably a "signed static value" it is one that isn't provided by IPP. What makes the certificate fingerprint different is that it is taken from the printer's certificate. And that fingerprint or certificate can be known to the Authentication Service via the registration process, so it can be verified or looked up by the Authentication Service.
>> Yes, this is called "certificate pinning". But then you have to refresh the fingerprint saved in the Authentication Service every time you issue a new certificate for a printer. Moreover, several printers may have the same certificate because:
> - you have a print server with several IPP printers, they all have the same certificate (their URLs have the same hostname)
> - you have a public Printing Service with many infrastructure printers, they all may have the same certificate (their URLs differ only by a path and/or by a query component)
> - you have a wildcard certificate
> - you have a multi-domain certificate
>>>>> And from your other reply:
>>>>> What about defining two types of printers?
>>>>>> A. "standard" printer
>>> - the client must validate its certificate
>>> - the client sends to the AS URL of the printer (without any addition like a fingerprint of the certificate)
>>> - the AS must verify the printer's URL
>>>>>> B. "certificate-based" printer
>>> - the client DOES NOT validate the printer's certificate (but uses it)
>>> - the client sends to the AS URL of the printer AND the fingerprint of the printer's certificate
>>> - the AS must verify both the printer's URL AND the fingerprint of the printer's certificate
>>>>>> It would make implementations of the client, the AS, and the printer slightly more complicated, but maybe it is worth it.
>>> Both the client and the AS must be aware about the type of the printer.
>>>>>>>>> I think we could mandate "certificate-based" for everything and then there aren't two variants.
>> The "standard" printer is a must for public services and corporate networks with print servers. Certificate pinning was empirically proved unsecure for the long run (see the link from my previous email).
> The "certificate-based" printer is a kind of workaround when:
> - the printer does not have FQDN
> - the certificate on the printer cannot be replaced and is invalid (out of date or self-signed)
> - you set up an artificial environment for testing/development purposes
>>>>>> Again, why should the Client submit both the URI and the fingerprint?
> See my note above about several printers having the same certificate.
>>> On Tue, Dec 6, 2022 at 8:28 PM Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
>> Hi Piotr,
>>>>> On Dec 6, 2022, at 1:05 PM, Piotr Pawliczek <pawliczek at google.com <mailto:pawliczek at google.com>> wrote:
>>>>>> CAUTION: External Email
>>> Hi Smith,
>>>>>> I divided your message into 3 parts and responded to them separately.
>>>>>> 1.
>>>> I understand that when the Printer is reachable at a hostname resolvable via infrastructure DNS, and the Printer holds a TLS certificate issued by a trusted CA, the Client can establish trust in the Printer's identity similarly to the trust a web browser can establish with a website, such as www.pwg.org <http://www.pwg.org/>. The Authentication Service and the Printer can establish mutual trust using much the same method (possibly via mutual TLS authentication).
>>>>>> Actually, the user must trust www.pwg.org <http://www.pwg.org/>. The certificate only guarantees that the browser is really connecting to www.pwg.org <http://www.pwg.org/> (and that the connection is encrypted). The certificate says nothing about www.pwg.org <http://www.pwg.org/>. Everyone can get a signed certificate, the only requirement is to prove that you control the given domain (they usually ask to publish a given file on the claimed domain).
>>> Again, the trust is between the user and the hostname part of the given URL. TLS is only the tool to verify the identity of the domain and make the connection secure.
>>>> Agree. 😊
>>>>> The problem with printers is that users do not verify their URLs like they do when browsing the internet. So, the Authorization Server must do it. This is why we have to send to the AS the priner's URL locked by its certificate.
>>>> I'm not sure I agree with that entirely but for print server hosted printer URLs, whether on-premises or in the cloud, that is certainly true.
>>>>> Another problem is that a client can access multiple printers with different URLs managed by the same AS, which does not fit into "standard" OAuth2/OpenID use cases. With the standard approach, the client should ask the user about each printer separately.
>>>> I'm not sure that I follow you here. Are you suggesting that if printing was following the more conventional OAuth 2.0 or OIDC use cases, each printer would have its own Authentication Service?
>>>>>>>>>>> 2.
>>>> That doesn't work for the "local printer" case, as we have already discussed. A Client may depend on a TOFU / certificate pinning model to establish some level of trust in the Printer in this scenario, since ".local." domain hostnames aren't registered in the global DNS. That works reasonably well for purely local printing where the trust expectations are arguably lower. The owner / operator may implement DNS and provision the printer with a certificate issued by a trusted CA, but then it is supported by infrastructure DNS and so falls under the model previously described.
>>>>>> Actually, pinning certificates is a very strong technique from the "mathematical" point of view, and works also with self-signed certificates. But, it is generally discouraged in the public network (see the full story: https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning <https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning>). On the other hand, it may be quite useful in small local
>>> networks or with mDNS hostnames.
>>>> Yep, and already widely used as you describe. 😊
>>>>> This is why I want the client to forward a fingerprint of the printer's certificate to AS.
>>>> I re-read your slides from the May F2F and I found you taking this position on slides 14 and 17. Sorry for being slow - I like this idea.
>>>> There is no reason why this couldn't be used for both "local" printers and printers with a routable FQDN. But you don't describe how the printer's certificate fingerprint will be conveyed along with the printer URI on slide 17. Can you expand on that a bit? And why is the fingerprint alone not sufficient?
>>>>> 3.
>>>> Either of these are methods for establishing trust between two directly communicating peers (Client and Authentication Service, Client and Printer, Authentication Service and Printer). But what we are trying to figure out with the resource identifier is a value that the Client uses to identify the Printer to the Authentication Service in an unimpeachable way. It should be a value that can be clearly validated by the Authentication Service and it should not be spoof-able in the same way that a DNS hostname can be spoofed or a UUID can be spoofed. Moreover, it should be a value that could only be provided by the printer if it had been registered with the Authentication Service. This could be a signed static value (some in HP have suggested a JWS?) or it could be a temporary / dynamic value that the Printer would request from the Authentication Service similar to how a Device Authorization Grant works.
>>>>>> Consider the following scenario: I connect to a printer and ask for this token(="a signed static value"). Then, I can pretend to be the printer to other users (I have the token, right?), and even better, forward print jobs they are sending to me to the real printer. This is a classic example of man-in-the-middle.
>>>> Agree in general any static value provided by an IPP attribute is unsound - it can be scooped up by anybody and presented as its own.
>>>> Although an X.509 certificate is arguably a "signed static value" it is one that isn't provided by IPP. What makes the certificate fingerprint different is that it is taken from the printer's certificate. And that fingerprint or certificate can be known to the Authentication Service via the registration process, so it can be verified or looked up by the Authentication Service.
>>>>>> And from your other reply:
>>>>> What about defining two types of printers?
>>>>>> A. "standard" printer
>>> - the client must validate its certificate
>>> - the client sends to the AS URL of the printer (without any addition like a fingerprint of the certificate)
>>> - the AS must verify the printer's URL
>>>>>> B. "certificate-based" printer
>>> - the client DOES NOT validate the printer's certificate (but uses it)
>>> - the client sends to the AS URL of the printer AND the fingerprint of the printer's certificate
>>> - the AS must verify both the printer's URL AND the fingerprint of the printer's certificate
>>>>>> It would make implementations of the client, the AS, and the printer slightly more complicated, but maybe it is worth it.
>>> Both the client and the AS must be aware about the type of the printer.
>>>>>>>>> I think we could mandate "certificate-based" for everything and then there aren't two variants.
>>>> Again, why should the Client submit both the URI and the fingerprint?
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20221215/b0c33313/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20221215/b0c33313/attachment.sig>