deviceAccessCheck rule for talaria

[utsavbatra5]

We were trying to enable deviceAccessCheck rule for talaria by putting the check on the device "trust" parameter.

The config that we have maintained is:
deviceAccessCheck:
type: "enforce"
sep: ">"
checks:
-
name: "Devices with trust level > 2000"
deviceCredentialPath: "trust>2000"
inputValue: 2000
op: gt

or just having the deviceCredentialPath = "trust". But in no scenario, its restricting the device.

Can you please advice regarding the correct format for deviceCredentialPath?

The payload looks something like this below where we are trying to have a check on the field trust
{
"aud": "XMiDT",
"capabilities": [
"x1:issuer:test:.*:all"
],
"mac": "112233446538",
"partner-id": "comcast",
"serial": "mock-rdkb-simulator",
"sub": "client-supplied",
"trust": 1000
}

[JC000]

Our trust model was developed to allow connections from devices that have a minimum level of trust to facilitate the configuration of a "blank" device. Note I didn't say "zero trust". That can just be one of the options. Trust levels are associated with each connection and (currently) are not reevaluated during the connection's life (i.e. if a token expired while the device is connected). There are three distinct enforcement points for trust.

1. Connections - you may choose to reject connections that don't present a credentials for a minimum level of trust (including having zero trust credentials). Our code doesn't current do this.
2. Southbound messages (API requests) - you may choose to reject messages which include a trust requirement that a connection does not meet.
3. Northbound messages (events) - you may choose to reject messages which include a trust requirement that a connection does not meet.

I'm not sure where the code currently is, in terms of implementing these enforcement functions.

[johnabass]

I wouldn't use "fail open", as that term is more general. It's accurate, but in this specific case what we're really saying is that talaria requires a JWT when that setting is true. So I'd call it requireJWT or requireSAT or something.

The other thing is we might want to add explicit trust levels in talaria that are easier to set. Something like:

deviceAccessCheck:
    requireSAT: true
    minimumTrustToConnect: 50
    minimumTrustToReceive: 1000

My naming is a bit clumsy. But the basic idea would be we can set an explicit minimum trust for a device to participate in certain behaviors. My rationale for this is that it's probably ok for any device to connect and send events. But for API calls we might want clients to require a trust to receive certain messages or perform certain operations.

[schmidtw]

@johnabass posted a better version of what I wrote up. :)

[schmidtw]

I'm not sure if separating out the requireJWT makes sense ... like what if that is set to false and minimumTrustToConnect is set to 50? I think the use of the .*Trust.* configuration parameters probably should call out that they must come from cryptographicly secure channels.

The minimumTrustToReceive (or send) maybe should be focused on "unsolicited events" (WRP Events vs Req/Resp) and limit the connection to only respond to requests from the cloud side. This will stop unwanted/trusted events leaving containment. Example:

deviceAccessCheck:
    minimumTrustToConnect: 50
    minimumTrustToSendUnsolicitedWrp: 1000
    minimumTrustToRespondToWrpRequest: 1000

[JC000]

I think having the option for an operator to control whether or not to fail open is a good feature to have. We would gladly accept code contribution from the community for this feature.

However, I would strongly recommend each operator carefully consider the consequences of operating in the "fail close" mode. What would happen if certificates of "blank" devices expire? Is there an out-of-band mechanism for upgrading the certificate? What you don't want to happen is a scenario where a device, that has been sitting in a warehouse for a long time, becoming as useful as a paper weight. Note that these are questions that must be considered in conjunction with your particular implementation of the trust token issuer, whether you use Themis or not. Does it always return a token? Even when presented with an invalid certificate? Does it have a authN backend that uses other real time data? Maybe a RSA token?

[joe94]

Since deviceAccessCheck addresses enforcement point (2) JC originally mentioned, it might be a good idea to have a new config section that specifically addresses enforcement (1). After some discussion with the team, I found the section could look something like this:

deviceRegistration:
    # Set to true if devices MUST present a JWT to register with XMiDT.
    # If set the false, devices connected has an effective trust value of zero.
    requireJWT: false

If you guys are interested in developing this feature, I can help by creating a more detailed issue on how you could go about implementing it. We have written similar code that you could use as a pattern 👍