attachment
<html><head><meta http-equiv="content-type" content="text/html; charset=us-ascii"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Piotr and Mike,<div><br></div><div>Sorry for the slow response.<br><div><br></div><div>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.</div><div><br></div><div><div>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 <a href="http://www.pwg.org">www.pwg.org</a>. The Authentication Service and the Printer can establish mutual trust using much the same method (possibly via mutual TLS authentication).</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Perhaps we can discuss with some pictures this Thursday?</div><div><br></div></div><div><div>
Smith<br><br>/**<br> Smith Kennedy<br> HP Inc.<br>*/
</div>
<div><br><blockquote type="cite"><div>On Nov 30, 2022, at 11:12 AM, Piotr Pawliczek <pawliczek@google.com> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div>
<font face="" calibri??=""><b><span style="font-size:11.0pt;line-height:107%; color:red">CAUTION: External Email
</span></b></font>
<div>
<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>
</div>
</div>
</div></blockquote></div><br></div></div></body></html>