Why only using grant_type=password, when it is possible to use grant=client_credentials (see RTC6749 Clause 4.4 Client Credentials Grant), where the client credential is the peer certificate in the TLS communication?
This will avoid to store an additional secret in the client (peer certificate's private key is already there).
Moreover, the only use of grant=password will prevent the use of OAuth with embedded device. RFC 6749 Clause 4.3.1 specifies that the user/password shall not be stored:
"The client MUST discard the credentials once an access token has been obtained."
I propose to add the following Clause to the standard:
XX.3.10 Use of grant_type=client_credentials
This optional feature intends to allow OAuth to be also used where grant_type=password grant cannot or will not be used, e.g. embedded client device.
This feature is base on RFC 6749 4.4. Client Credentials Grant using the parameter grant_type=client_credentials and the credential is the peer certificate in TLS communication. If 'client_id' parameter is not present, it is a local matter, if bearer is encrypted or not.
With best regards,
Philippe Goetz
Siemens AG
Infrastructure & Cities Sector
Building Technologies Division
IC BT SSP ES R&D DE MCH
Siemensallee 84
76187 Karlsruhe, Germany
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't disagree that there may be a use case for the "device granularity" authorization which you are describing, and I will I will discuss support for that later, but first let me repeat what I said in another thread to set the stage about granularity:
--- repeated from other thread---
Also, on a related note, the idea of using a client certificate alone to obtain an authorization might be too course-grained. The model currently assumed is to have authorization granted to entities (humans or processes are the "Resource Owner"), not to devices. A device and its TLS certificate is just a conduit for the passing of the credentials, not the credentials themselves. In fact, as written, mutual authentication is not even a requirement. Therefore the TLS certificate of the client device is not a required part of the authorization decision, because the client device is not the "Resource Owner" - some human or process acting through the client is the actual entity that is being authorized.
---end repetition---
Responding to you comment is in two parts, then.
Part 1 is about using grant=client_credentials (RFC 6749 Section 4.4). Because there are potentially so many (thousands) of devices in a BACnet system, it was not anticipated that the Authorization Server be required to maintain copies of each certificate. As it says, mutual (client) authentication is optional.
Before going any further, it is important to note that, as currently written, TLS certificates are installed at deployment time, by the customers' agents. They do not come from the manufacturer. The scenario is this: It is an almost a certainty that a customer will not want to get certificates from a "real" CA, like Verisign, for thousands of devices (cost and turnaround time make this completely impractical). Therefore the customer would make a single self-signed certificate that is distributed to all devices as the "root" certificate. It then can use that root to sign derivatives to be "device" certificates.
Since there are so many possible device-to-device communications that may pop up from time to time (adding a alarm recipient or a COV subscription makes some device need to talk to another device on-the-fly), requiring each device to have the certificate of the all possible peer devices did not seem practical. That is the intended purpose of the "root" certificate. When a device is told to talk to another device, it connects to that device and verifies that the peer devices' certificate came from the same root as its own device certificate; it will then know that the peer device is part of the "family" and can establish a conversation. Support for multiple root certs was discussed but tabled until we de decided that we really need that level of complication. It might be that separate "circles of trust" might want separate roots, or that a single physical device might talk on two ports with two certs... more discussion and scenarios are needed.
Now back to your question about using the device's TLS certificate as client credentials. You said "This will avoid to store an additional secret in the client (peer certificate's private key is already there)." but as I said above, it was not anticipated that the authorization server have the certificate of every individual device. That is an interesting possibility, but not one that was expected to be required. And even if it did, the granularity for the authorization decisions would only be possible at the device level, not based on "user".
In Clause 24 (and echoed in the "user-id" and "role-id" fields of the token), we did anticipate that there would be user-less device-to-device communications that are authorized to be taken by "the system itself", to quote Clause 24.2.11. This may be a case where device-level granularity is sufficient, so I'm am not arguing against that possibility entirely.
I can see a use case where an embedded device asks an authorization server for a token using grant=client_credentials and the following are checked: 1) if the device's individual certificate is known to the auth server (as you assumed), then that fact can be used as part of an individual auth decision, or 2) the device's individual certificate is not known to the auth server then auth server can check the root and make auth decisions based on what any family member is allowed to do.
Part 2 of this response is easier. You mentioned that Section .3.1 specifies that the credentials MUST not be stored, and that makes it impossible for an embedded client. But looking at the diagram in RFC 6749 Section 4.3, we see that the "Resource Owner" is distinct from the "Client". Thus it is appropriate for a "process" in an embedded device to be the "resource Owner, and thus own the credentials, and that the "Client" on that device passes those credentials through to the auth server. This embedded "Client" does then discard them as required, but the "process" that is the embedded "Resource Owner" retains them securely (as securely as the TLS private key is retained - we have to assume some level of security for embedded storage)
As always, I'm sure there is more to talk about here. Thanks for some excellent ideas.
Dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why only using grant_type=password, when it is possible to use grant=client_credentials (see RTC6749 Clause 4.4 Client Credentials Grant), where the client credential is the peer certificate in the TLS communication?
This will avoid to store an additional secret in the client (peer certificate's private key is already there).
Moreover, the only use of grant=password will prevent the use of OAuth with embedded device. RFC 6749 Clause 4.3.1 specifies that the user/password shall not be stored:
"The client MUST discard the credentials once an access token has been obtained."
I propose to add the following Clause to the standard:
XX.3.10 Use of grant_type=client_credentials
This optional feature intends to allow OAuth to be also used where grant_type=password grant cannot or will not be used, e.g. embedded client device.
This feature is base on RFC 6749 4.4. Client Credentials Grant using the parameter grant_type=client_credentials and the credential is the peer certificate in TLS communication. If 'client_id' parameter is not present, it is a local matter, if bearer is encrypted or not.
With best regards,
Philippe Goetz
Siemens AG
Infrastructure & Cities Sector
Building Technologies Division
IC BT SSP ES R&D DE MCH
Siemensallee 84
76187 Karlsruhe, Germany
I don't disagree that there may be a use case for the "device granularity" authorization which you are describing, and I will I will discuss support for that later, but first let me repeat what I said in another thread to set the stage about granularity:
--- repeated from other thread---
Also, on a related note, the idea of using a client certificate alone to obtain an authorization might be too course-grained. The model currently assumed is to have authorization granted to entities (humans or processes are the "Resource Owner"), not to devices. A device and its TLS certificate is just a conduit for the passing of the credentials, not the credentials themselves. In fact, as written, mutual authentication is not even a requirement. Therefore the TLS certificate of the client device is not a required part of the authorization decision, because the client device is not the "Resource Owner" - some human or process acting through the client is the actual entity that is being authorized.
---end repetition---
Responding to you comment is in two parts, then.
Part 1 is about using grant=client_credentials (RFC 6749 Section 4.4). Because there are potentially so many (thousands) of devices in a BACnet system, it was not anticipated that the Authorization Server be required to maintain copies of each certificate. As it says, mutual (client) authentication is optional.
Before going any further, it is important to note that, as currently written, TLS certificates are installed at deployment time, by the customers' agents. They do not come from the manufacturer. The scenario is this: It is an almost a certainty that a customer will not want to get certificates from a "real" CA, like Verisign, for thousands of devices (cost and turnaround time make this completely impractical). Therefore the customer would make a single self-signed certificate that is distributed to all devices as the "root" certificate. It then can use that root to sign derivatives to be "device" certificates.
Since there are so many possible device-to-device communications that may pop up from time to time (adding a alarm recipient or a COV subscription makes some device need to talk to another device on-the-fly), requiring each device to have the certificate of the all possible peer devices did not seem practical. That is the intended purpose of the "root" certificate. When a device is told to talk to another device, it connects to that device and verifies that the peer devices' certificate came from the same root as its own device certificate; it will then know that the peer device is part of the "family" and can establish a conversation. Support for multiple root certs was discussed but tabled until we de decided that we really need that level of complication. It might be that separate "circles of trust" might want separate roots, or that a single physical device might talk on two ports with two certs... more discussion and scenarios are needed.
Now back to your question about using the device's TLS certificate as client credentials. You said "This will avoid to store an additional secret in the client (peer certificate's private key is already there)." but as I said above, it was not anticipated that the authorization server have the certificate of every individual device. That is an interesting possibility, but not one that was expected to be required. And even if it did, the granularity for the authorization decisions would only be possible at the device level, not based on "user".
In Clause 24 (and echoed in the "user-id" and "role-id" fields of the token), we did anticipate that there would be user-less device-to-device communications that are authorized to be taken by "the system itself", to quote Clause 24.2.11. This may be a case where device-level granularity is sufficient, so I'm am not arguing against that possibility entirely.
I can see a use case where an embedded device asks an authorization server for a token using grant=client_credentials and the following are checked: 1) if the device's individual certificate is known to the auth server (as you assumed), then that fact can be used as part of an individual auth decision, or 2) the device's individual certificate is not known to the auth server then auth server can check the root and make auth decisions based on what any family member is allowed to do.
Part 2 of this response is easier. You mentioned that Section .3.1 specifies that the credentials MUST not be stored, and that makes it impossible for an embedded client. But looking at the diagram in RFC 6749 Section 4.3, we see that the "Resource Owner" is distinct from the "Client". Thus it is appropriate for a "process" in an embedded device to be the "resource Owner, and thus own the credentials, and that the "Client" on that device passes those credentials through to the auth server. This embedded "Client" does then discard them as required, but the "process" that is the embedded "Resource Owner" retains them securely (as securely as the TLS private key is retained - we have to assume some level of security for embedded storage)
As always, I'm sure there is more to talk about here. Thanks for some excellent ideas.
Dave