attachment
<div dir="ltr"><div><br></div><div>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.</div><div>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.</div><div>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.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 30, 2022 at 7:57 AM Kennedy, Smith (Wireless & IPP Standards) via ipp <<a href="mailto:ipp@pwg.org">ipp@pwg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi Mike,<br>
<div><br><blockquote type="cite"><div>On Nov 9, 2022, at 7:39 AM, Michael Sweet <<a href="mailto:msweet@msweet.org" target="_blank">msweet@msweet.org</a>> wrote:</div><br><div>CAUTION: External Email<br><br><div style="margin:0px"><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(127,127,127)"><b>From: </b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">Michael Sweet <<a href="mailto:msweet@msweet.org" target="_blank">msweet@msweet.org</a>><br></span></div><div style="margin:0px"><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(127,127,127)"><b>Subject: </b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif"><b>Re: [IPP] Add "oauth-authorization-resource" attribute?</b><br></span></div><div style="margin:0px"><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(127,127,127)"><b>Date: </b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">November 9, 2022 at 7:39:14 AM MST<br></span></div><div style="margin:0px"><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(127,127,127)"><b>To: </b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">"Kennedy, Smith (Wireless & IPP Standards)" <<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>><br></span></div><div style="margin:0px"><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif;color:rgb(127,127,127)"><b>Cc: </b></span><span style="font-family:-webkit-system-font,"Helvetica Neue",Helvetica,sans-serif">PWG IPP Workgroup <<a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a>><br></span></div><br><br>Smith,<br><br><blockquote type="cite">On Nov 8, 2022, at 11:56 PM, Kennedy, Smith (Wireless & IPP Standards) <<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>> wrote:<br>...<br>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.<br></blockquote><br>Yes, for authenticating the System/Printer/Proxy to the auth server - that's one of the things MS does for their Universal Print Service.<br><br>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.<br><br><blockquote type="cite">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).<br></blockquote><br>There is no way to validate the value, so its use in securing the authorization token would be lost.<br><br>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!)<br></div></blockquote><div><br></div>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.</div><div><br></div><div>The Client is still free to compare the elements of "printer-uri" with the fields in the Printer's X.509 TLS certificate.</div><div><br></div></div>_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp" rel="noreferrer" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
</blockquote></div>