Access to the Security Object is imprecisely specified

[kFYatek]

According to the OMA-TS-LightweightM2M-V1_0-20161123-D revision of the specification, the Security Object is generally inaccessible via the Device Management and Service Enablement Interface, and inaccessible by non-bootstrap LWM2M servers in general, because:

• It is forbidden to report its instances in the Register message, as specified in Table 7 under 5.3.1 (Register): "The list of Objects supported and Object Instances available on the LWM2M Client (Security Object ID:0 MUST not be part of this list)."
• It is forbidden to report its instances in the Update message, as specified in section 5.3.2 (Update): "The Security Object ID:0 MUST not be part of Update Objects and Object Instances list."
• It is impossible to invoke Read, Write, Execute or Observe operations on any of the Security Object resources, because section E.1 (LWM2M Object: LWM2M Security) specifies that "These LWM2M Object Resources MUST only be changed by a LWM2M Bootstrap-Server or Bootstrap from Smartcard and MUST NOT be accessible by any other LWM2M Server.", and the Resource definitions specify empty set of Operations for each resource.
• Likewise, Create operation is impossible because it is impossible to create a valid instance without the ability to write to the resources, which is impossible as described above.
• In a multiple-server environment, the client is required to perform access control checks as described in section 7.3 (Access Control), and the range for the "Object ID" (ID:0) resource in the Access Control object definition is specified in section E.3 as 1-65534, making it impossible to grant any access to the Security Object (ID:0).

The last case also makes it generally impossible to invoke the Delete operation, at least in the multi-server environment.

However, in a single-server environment, there seems to be no part of the specification that would forbid performing the Delete operation - such action would effectively mean that the LWM2M Server could remove its own Account, perhaps putting the device in a state when it needs to bootstrap again - which does not seem to be entirely unreasonable. However, as the same action is clearly forbidden in a multi-server environment, it's easy to guess that it's an unintentional omission in the specification.

The biggest question, however, are the Write Attributes and Discover operations called on the Security Object or its instances or their resources. According to section 7.3.2 (Authorization), to perform these operations, no access rights are required. While the Write Attributes operation is largely meaningless for a Security Object (observing its resources is impossible anyway, so any written attributes are ignored nevertheless), the Discover operation can potentially have some unintended consequences: a server could get to know how many other servers are there in the environment; potentially existence (or not) of Optional resources within a Security Object instance may reveal some information about presence (or not) of a bootstrap server or SMS channel. This doesn't seem like a big security hole, but may be unintended.

However, it's not explicitly forbidden. Section E.1 only states that the Security Object Resources "MUST NOT be accessible by any other LWM2M Server" than the Bootstrap Server - and the Discover operation is not really "accessing" any resources.

The November revisions of the 1.0 spec also introduced the BOOTSTRAP DISCOVER operation. In particular, section 5.2.7.2 (Bootstrap DISCOVER) reads:

The “Discover” operation on the Bootstrap Interface is used to discover which LWM2M Objects and Object Instances are supported by a certain LWM2M Client. In particular, the Security Object Instances (ID:0) are reported, while they are not accessible in Device Management and Service Enablement Interface.

(emphasis added by me)

This would suggest that the regular variant of Bootstrap should not be allowed for the Security Object - however, as mentioned earlier, this does not seem to be stated anywhere else, and the definition of one operation does not seem to be really authoritative for behaviour of another.

I think that it would be appropriate to add explicit wording such as "Any operation of the Device Management and Service Enablement interface attempted with the Object ID parameter referring to the the Security Object (ID:0) MUST NOT be performed and MUST result in an Unauthorized response" in some appropriate section of the specification.

[dnav]

Hi, If I understand your message correctly, all the ambiguity comes from not having a clear definition of "being accessible". Your point is taken.

Regards,

[hannestschofenig]

The CR is 227 for this request is http://member.openmobilealliance.org/ftp/Public_documents/DM/LightweightM2M/2017/OMA-DM-LightweightM2M-2017-0227-CR_Security_Object_Clarification.zip