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

"Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email protected]> Thu, 15 Dec 2022 16:32:44 +0000
Newsgroups	gmane.ietf.ipp
Message-ID	<[email protected]>
Hi Mike,

> On Dec 15, 2022, at 8:14 AM, Michael Sweet <[email protected]> wrote:
> 
> CAUTION: External Email
> 
> From: Michael Sweet <[email protected]>
> Subject: Re: [IPP] Add "oauth-authorization-resource" attribute?
> Date: December 15, 2022 at 8:14:25 AM MST
> To: "Kennedy, Smith (Wireless & IPP Standards)" <[email protected]>, PWG IPP Workgroup <[email protected]>
> Cc: Piotr Pawliczek <[email protected]>
> 
> 
> Smith,
> 
>> On Dec 14, 2022, at 10:18 PM, Kennedy, Smith (Wireless & IPP Standards) via ipp <[email protected]> wrote:
>> 
>> Signed PGP part
>> 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?
> 
> OK, so this gets us back to the subject of X.509 certificate validation.  Current IPP usage allows for TOFU with self-signed certificates, but we have identified this as a weak point when using OAuth.  The normal way of dealing with this involves using CA-signed certificates, where the CA for a printer will typically be:
> 
> 1. A local enterprise certificate server that provides signed certificates; the root (CA) certificate is bound to the domain (ActiveDirectory or similar)
> 2. A remote certificate server that provides signed certificates; the root (CA) certificate is either globally trusted or bound to the domain (Azure Universal Print Service or similar)
> 3. An Internet public certificate authority that provides signed certificates; this can be provisioned manually or via ACME if the printer is accessible globally (yeck), and the root (CA) certificate is well-known
> 4. (New, not yet standardized) A local ACME server that provides signed certificates; the root (CA) certificate is bound to the network via DHCP or DNS-SD.
> 
> Only the last one supports mDNS (.local) hostnames, the rest force you to use an actual domain name for the printer.
> 
> You can't send a fingerprint from the Client to the Authorization Server (AS) because a) there isn't a protocol for that

I wondered about that when Piotr mentioned it before since the token exchange doesn't have a parameter specifically for it. I was thinking that we could do something gross like provide a URI instead of just a hostname for the resource parameter to token exchange endpoint, and embed the fingerprint in the URI. It seems like we might need to send a URI anyway since the print server may host more than one printer, and the token exchange ought to target a specific printer, not just a "host". But this is veering into questionable terrain.

> and b) even if you did there is no way for the AS to authenticate the fingerprint (i.e. the resource URI is the only information it has about the printer that is the same as what the Client sees, the AS may never see the Printer's X.509 certificate...)

I thought about that too - ideally the registration process would provision the printer with a certificate issued by the same CA as the Authentication Service and have other fields that the Client could use to indicate the printer's connection to the Authentication Service's control space / domain / ecosystem / whatever. Alternately, the Authentication Service would be given the printer's certificate (possibly self-signed), but that is weaker in a few ways.

If the Authentication Service has no knowledge of the printer's certificate, then a bunch of this is even weaker from a trust establishment point of view.

_______________________________________________
ipp mailing list
[email protected]
https://www.pwg.org/mailman/listinfo/ipp
signature.asc (application/pgp-signature, 833 B)