Re: Add "oauth-authorization-resource" attribute?

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 <[email protected]> wrote:

> Hi Mike,
>
> On Nov 9, 2022, at 7:39 AM, Michael Sweet <[email protected]> wrote:
>
> CAUTION: External Email
>
> *From: *Michael Sweet <[email protected]>
> *Subject: **Re: [IPP] Add "oauth-authorization-resource" attribute?*
> *Date: *November 9, 2022 at 7:39:14 AM MST
> *To: *"Kennedy, Smith (Wireless & IPP Standards)" <[email protected]>
> *Cc: *PWG IPP Workgroup <[email protected]>
>
>
> Smith,
>
> On Nov 8, 2022, at 11:56 PM, Kennedy, Smith (Wireless & IPP Standards) <
> [email protected]> 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
> [email protected]
> https://www.pwg.org/mailman/listinfo/ipp
>

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