Smith,
For sure we should talk about this at tomorrow's concall, but I'll respond to some of your responses below anyways... :)
> On Apr 11, 2023, at 10:58 PM, Kennedy, Smith Wireless & IPP Standards <smith.kennedy at hp.com> wrote:
>> ...
>> - Slide 6: We don't do TOFU for OAuth Printers (#3.2)
>>> I know you and Piotr have arrived at this position but I haven't joined you there yet. 😊
>>> and the Client does the Token Exchange with the auth server, not the printer (#6)
>>> Yes...but the arcing #6 arrow is trying to illustrate the trust relationship that the device access token is trying to provide: (a) to have an artifact that can be used for #7, and (b) to validate the relationship between the Authentication Service and the Printer. Do you disagree with what I have in the "Mechanism" and "Comments" cells of Row 6 on slide 7?
I think the diagram is just confusing, then... :) WRT the comments column, I think "quality" is the wrong word for the trustworthiness of the resource URI.
>> - Slide 7: We don't do TOFU for OAuth Printers - this does not scale and is not trustworthy, resource identifier is printer URI so the trust depends on the hostname being unique (within the authorization framework/domain used) and TLS cert validation working
>>> I guess we will continue to discuss this in the meeting. It seems you (and perhaps Piotr) have decided that OAuth 2.0 authenticated local printing is impossible in the absence of a globally unique FQDN. I am still looking for a way to accommodate devices that are behind an IPv4 NAT with no globally unique FQDN, to satisfy Use Case #3 on slide 2.
The hostname doesn't need to be *globally* unique, just *locally* unique, where "local" means "within the authorization framework/domain/network", i.e., if you are using an Acme OpenID service, your printer's hostname just needs to be unique among printers connected to that auth service.
Generally speaking we are there by default with the typical "vendorXXxxXXxxXXxx" hostname that is used out-of-the-box. If somebody knows enough to change the default hostname, they should be capable of wrapping their heads around the need to provide a unique name within their network.
> The JWE and Fingerprint Resource Identifier options seemed like a pathway to support this, by accepting a reduced level of trust in the printer's certificate but using Token Exchange to validate that the Authentication Service can vouch for the identity of the printer because of the quality of the Resource Identifier. (This does depend on the Client fully trusting the Authentication Service, however. If both the printer and the Authentication Service are malicious then the Client is in trouble...how does OAuth 2.0 deal with that?)
The problem with JWE/JWS is that you need secrets from the Client, Printer, and auth service to establish that you are talking to the real Printer, which means a new operation or an extension to Get-Printer-Attributes or Get-System-Attributes that allows the Printer to provide a nested JWE/JWS that is signed by both the Printer and auth service (effectively duplicating what the TLS handshake and token exchange provides...)
Moreover, neither of your proposed solutions will work with existing OAuth implementations, which makes it hard to standardize on.
>> - Slide 8: Again, we've already talked about TOFU and decided we don't allow it with OAuth because it is *not* trustworthy/scalable. The "quality" of the resource ID is the uniqueness of the printer URI (the URI the Client is using to connect to the printer, and thus the *resource* being used/authorized).
>>> I'm not questioning the utility or the quality of the globally routable FQDN / printer URI solution, and I'm not trying to reject it. My position is that the globally routable FQDN / printer URI solution does not satisfy all the use cases that I and my colleagues at HP believe need to be supported, and I'm trying to find alternatives to close that gap.
See my prior comments. We just need the hostname to be "unique enough".
>> - Slide 9: The resource ID is not cryptographically signed, so there is no question of trustworthiness. If the hostname in the URI is unique, the TLS cert validation provides the guarantee/trustworthiness of the resource ID and the token exchange ensures that the printer is registered with the auth server. Thus, the key is NOT the resource ID/URI but the X.509 certificate used by the printer.
>>> I'm sorry but I'm not quite following what you are saying above about slide 9.
A Man-in-the-Middle attack depends on:
1. Impersonating the Printer (valid X.509 cert and key) or running malicious code on the Printer/System to get past X.509 validation of the Printer/System, and
2. Impersonating the Authorization Server (valid X.509 cert and key), running malicious code on the Authorization Server, or changing the Authorization Server metadata to get past the resource validation during token exchange.
#1 is a problem that exists with or without OAuth - thus my IoT ACME work to make impersonation harder. The malicious code issue isn't something we can do much about in the standards world... And the resource ID/printer URI/system URI you use to talk to the Printer/System has to be used to access the corresponding service/object...
#2 is independent of the resource ID/printer URI/system URI, and isn't even unique to OAuth (see my comments for #1).
In short, token exchange validates the *resource* (Printer/System), which can only happen if the ID is correct. The question isn't of trust but of correctness.
>> - Slide 11: So the Token Exchange spec isn't particularly clear, but the resource ID *is* the URI/URL for the resource.
>>> You referenced RFC 8693 and cited section 2.1's definition of "resource" below, which specifies that the resource MUST be an absolute URI, which typically is an https URL, but doesn't have to be.
>>> For IPP that probably means the https equivalent URL as specified in RFC 7472 (ipps URI scheme). JWE doesn't help because you need to use a client-supplied secret to demonstrate ownership of the private key (necessary to prevent MITM attacks).
>>> By "client" do you mean the IPP Client? And what "private key" are you talking about in this context?
Private key as in the private key for RSA/ECDSA encryption/signing, which allows the other party to verify using the corresponding public key.
>> And the X.509 fingerprint likewise isn't any help, not to mention short-lived certificates make scaling an issue.
>>> Unless I am mistaken, the fingerprint of an X.509 certificate is unique for each certificate. If the Printer registers the fingerprint of its current TLS certificate (CA-issued or self-signed) with the Authentication Service, and the Client uses the fingerprint of the printer's X.509 TLS certificate as the Resource Identifier, and the Authentication Service returns an Access Token, then why is the Client unable to have confidence that the Authentication Service and the Printer have a relationship with one another, and by extension that the Printer can better trust the Printer?
Current proposals for maximum certificate life are pushing for shorter lengths (3 months or less) which means that fingerprint is changing frequently. No different than allowing a printer's hostname to be changed (needs a new certificate), updating the root (CA) certificate, etc.
> ...
> But I think I must have not conveyed my point clearly because I think you misunderstood what I was trying to convey. My point was that the Authentication Service may support only one of the types listed on slide 11. Unless we concur to stand pat with only global FQDN / CA-issued cert / printer-URI, the Client will need a way to discover what resource identifier value to provide to the Authentication Service.
That's on our TODO list, with one option simply being to use the first printer-uri corresponding to the entry with "oauth" for the xri/uri-authentication value.
Again, our prior discussions had (I thought) concluded that for OAuth to be trustworthy, the hostname needs to be unique within the domain and the certificate needs to use a trusted root (from a public CA or otherwise), so that *trust* can be managed centrally/automatically.
________________________
Michael Sweet
-------------- 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/20230412/9a9215f6/attachment.sig>