Hi Piotr and Mike,
Sorry for the slow response.
I don't think it is right to intermingle how the Client establishes trust in the Printer with how the Printer identifies itself to the Authentication Service.
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).
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.
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.
Perhaps we can discuss with some pictures this Thursday?
Smith
/**
Smith Kennedy
HP Inc.
*/
> On Nov 30, 2022, at 11:12 AM, Piotr Pawliczek <pawliczek at google.com> wrote:
>> CAUTION: External Email
>> The only thing that can identify the resource is the printer's URL, since it is the only value locked down by the printer's (valid!) certificate.
> When you take control over a host with a valid certificate, you can change everything but its URL. To change the URL you would need a new certificate and changes in DNS configuration.
> So, if you allow the client to use any self-reported ID as a resource ID (instead of the URL), this kind of host can impersonate any printer in the network.
>>>> On Wed, Nov 30, 2022 at 7:57 AM Kennedy, Smith (Wireless & IPP Standards) via ipp <ipp at pwg.org <mailto:ipp at pwg.org>> wrote:
>> Hi Mike,
>>>>> On Nov 9, 2022, at 7:39 AM, Michael Sweet <msweet at msweet.org <mailto:msweet at msweet.org>> wrote:
>>>>>> CAUTION: External Email
>>>>>> From: Michael Sweet <msweet at msweet.org <mailto:msweet at msweet.org>>
>>> Subject: Re: [IPP] Add "oauth-authorization-resource" attribute?
>>> Date: November 9, 2022 at 7:39:14 AM MST
>>> To: "Kennedy, Smith (Wireless & IPP Standards)" <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>>
>>> Cc: PWG IPP Workgroup <ipp at pwg.org <mailto:ipp at pwg.org>>
>>>>>>>>> Smith,
>>>>>>> On Nov 8, 2022, at 11:56 PM, Kennedy, Smith (Wireless & IPP Standards) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
>>>> ...
>>>> If an Authentication Service supports a certificate or some other more trustable artifact as a resource identifier, perhaps one provisioned to the printer at the time the printer is registered, that could improve the situation, right? I thought we discussed that at the August F2F.
>>>>>> Yes, for authenticating the System/Printer/Proxy to the auth server - that's one of the things MS does for their Universal Print Service.
>>>>>> The point of the Client passing the printer-uri/system-uri when doing token exchange is to limit the potential exposure of credentials. The Client will have already validated the Printer's X.509 certificate when it connects to do a Get-Printer-Attributes, and then the authorization server can validate that the System/Printer/Proxy has registered *that* printer-uri/system-uri. That combined with the Client validating the oauth-authorization-server-uri value will minimize the likelihood of a breach.
>>>>>>> Regardless, I think that it would be better for the client to use the value provided by a purpose-defined but abstract attribute like "oauth-authorization-resource-id" instead of instructing or guiding clients to use "printer-uuid" or "printer-uri". The value held by "oauth-authorization-resource-id" could be a URI or a UUID (printer-uuid or some other UUID).
>>>>>> There is no way to validate the value, so its use in securing the authorization token would be lost.
>>>>>> With the URI, the Client resolves the address, connects to the service, negotiates a secure connection via TLS, and is able to validate the server-side X.509 certificate against a trusted root CA (no self-signed certs if you are using OAuth!)
>>>> Agree, but I don't think that eliminates the value that "oauth-authorization-resource-id" provides. The value held by "oauth-authorization-resource-id" could be whatever is needed to identify the resource to the Authentication Service. In some cases it may be "printer-uuid" or "printer-uri" or some unique value provisioned to the Printer by the Authentication Service during printer registration. Defining "oauth-authorization-resource-id" means we don't have to provide specific guidance as to what is provided in the OAuth 2.0 requests that require a resource ID to be specified as a parameter.
>>>> The Client is still free to compare the elements of "printer-uri" with the fields in the Printer's X.509 TLS certificate.
>>>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org <mailto:ipp at pwg.org>
>>https://www.pwg.org/mailman/listinfo/ipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20221206/87c8c407/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/20221206/87c8c407/attachment.sig>