w3c / wot-security

a repo exclusively for security to better manage issues and security considerations for WoT
https://w3c.github.io/wot-security/
18 stars 22 forks source link

Review IETF MUD draft specification and consider WoT alignment #153

Open mmccool opened 4 years ago

mmccool commented 4 years ago

Review the following MUD specification, and consider how it is or could be aligned with WoT TDs. In particular, would it be possible to derive MUD metadata from TD metadata or vice-versa? Is inconsistent terminology being used? Should we schedule a meeting with them? McCool will be at IETF107... https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-02

JKRhb commented 2 years ago

Regarding the alignment of WoT and MUD in general, we had a discussion in my University project a while ago. One interesting aspect that came up in this context was that WoT TD (as well as SDF by the way) currently only allows the description of Things that act as a server. In order to derive an accurate MUD file, however, you would also need to describe the client behavior of Things, e. g. if they need to connect to an update server or if they try to retrieve sensor data to fulfill their purpose.

One possible example I came up with in this regard was the JSON file below. Here, a field called behavior is used to describe the update behavior of a Thing, which retrieves updates them from a server under updates.example.com using a TCP connection (a complete URI is given as an alternative). The fields frequency and trafficSize, which in this case describe how often the update server is contated and how large the payload will probably be, could be used for anomaly detection.

Maybe we can use this as a starting point for further discussions. I think an alignment of MUD and WoT is quite interesting. However, I am not sure if the description of a Thing's client behavior could be out of scope of WoT and if we could/should simply link to a MUD file instead. Then again, I am not sure if a TD is too "high level" to serve as a way of emitting MUD URLs.

{
  "@context": "http://www.w3.org/ns/td",
  "title": "MyLampThing",
  "securityDefinitions": {
    "nosec_sc": {"scheme": "nosec"}
  },
  "security": "nosec_sc",
  "behavior": {
    "update": {
      "title": "Get updates from update server.",
      "frequency": 86400000, // Interval in miliseconds, in this case: one day
      "trafficSize": 100, // Estimated average payload size in bytes
      "connections": [
        {
          "dnsnames": [ "updates.example.com"],
          "transportProtocol": "TCP",
          "href": "https://updates.example.com", // Alternative
          "ipVersion": [4, 6],
          "directionInitiated": "from-device", // Probably obsolete information (taken from MUD)
          "fromPort": 443, // Single port ...
          "toPort": [5000, 5530] // or port range
        }
      ]
    },
    "retrieveSensorData": {
      "title": "Retrieve data from a temperature sensor.",
      "frequency": 900000, // Retrieves sensor data every 15 minutes
      "connections": [
        {
          ...
        }
      ]
    }
  }
}
JKRhb commented 2 years ago

@mmccool Did you see my comment above by any chance? Do you think there might be space for a brief discussion in one of the next security calls?

mmccool commented 2 years ago

Should discuss in our next charter. Marked as deferred for now.