PSK identity for DTLS over SMS

[kFYatek]

The SMS Secured mode for the Device End-point is defined to use DTLS encapsulated in SMS PDUs. Section 7.2.2.1.4, "DTLS supported authentication modes considerations", presents concerns related to various authentication modes and concludes that:

For that reason, only PSK-based authentication MUST be supported on SMS Channel using DTLS.

Section E.1, which defines the "LWM2M Security" Object, reinstates this standpoint in the description of Resource 6, "SMS Security Mode":

1: DTLS mode (Device terminated) PSK mode assumed

For proper operation of a DTLS client, two pieces of authentication data are necessary: the secret key and the key identity.

I assume that the DTLS secret key for SMS Security Mode 1 should be configured in the resource 8, "SMS Binding Secret Key(s)". However, there seem to be no resource to configure the identity (similar to resource 3 used for UDP binding).

• Should the PSK identity be taken from resource 3, the same as for the UDP channel? This would, however, pose a problem if a different security mode (e.g. RPK or certificate) is used for UDP - in that case the semantics of resource 3 are totally different.
• Should the PSK identity be taken from resource 7, "SMS Binding Key Parameters"? The specification does not say anything about that, but it would make sense, as it would be a similar manner of reusing resources as with the UDP channel keying resources, given that resource 7 as currently defined seems meaningful only for the Secure Packet Structure mode.
• Should the PSK identity be hardcoded to be empty or some other specific value?

Without resolving this problem, proper conforming implementation of the DTLS (Device terminated) SMS Security mode seems to be impossible.

[hannestschofenig]

We are looking into this issue by finding out who has attempted to implement this part of the specification. Reading through your description I do, however, also notice the challenge in developing an interoperable solution.

[jpradocueva]

DM WG needs to discuss this topic based on feedback.

[jpradocueva]

Comments provided by DM Working Group:

“PSK identity should be from resource 3, resource 7 is not related to DTLS it is purely related to SMS For harmonization of keys for UDP and TCP would be looked in LwM2M v1.1, there are no negative comments at this stage in the group.”

[kFYatek]

Does that mean that SMS Security Mode == 1 (DTLS PSK) is unusable when UDP Security Mode is set to anything else than 0 (PSK)?

[jpradocueva]

DM provided the following comment:

• Q: Does that mean that SMS Security Mode == 1 (DTLS PSK) is unusable when UDP Security Mode is set to anything else than 0 (PSK)?
• A: When two binding modes are used then two security object instances are needed since one instance can only be relevant to one binding. These security object instances may also use different credentials.

[kFYatek]

I'm sorry, but your interpretation does not seem to make much sense. Here is my reasoning:

• Let's suppose we have a Server object instance with Binding set to "US" or "UQS"
• Those two Security instances you are referring to would need to have the same Short Server ID (Resource 10) value, as they would both need to be paired with the same Server instance
• There seems to be no way of identifying which instance does refer to the UDP binding, and which one to the SMS binding; also note that in each instance, the Resources that specify UDP CoAP URI (0) and UDP Security Mode (2), among other UDP-related ones, are specified as Mandatory, so there would essentially be two configurations for the same UDP binding
• Also, it would mean that it is impossible to configure a device so that it could accept e.g. Server-initiated Bootstrap through either of UDP and SMS transports, because
  • section 5.2.2 of the spec says that "The LwM2M Client MUST have at most one LwM2M Bootstrap-Server Account"
  • the Bootstrap-Server Account is defined in section 3.2 as "LwM2M Security Object Instance with Bootstrap-Server Resource true"
  • according to your interpretation, to have both UDP and SMS connectivity with a given server, you need two LwM2M Security Object Instances - which is, as demonstrated, in direct contradiction with the explicit requirements of the spec in this (Bootstrap Server) case

Hence, I still strongly think that it is undebatable that for "US" and "UQS" Binding settings, both the UDP and SMS transports shall be configured within the same Security instance. If you can demonstrate otherwise, then please provide a detailed example (e.g. in the style of the spec's Appendx F) of how the contents of Security and Server objects should look like.

[hannestschofenig]

My personal perspective on this issue.

The way to find out whether the security object refers to the SMS or to the UDP binding is via the content of the LwM2M Server URI.

Regarding the bootstrap server limitation in LwM2M v1.0 it is true that currently we only support one bootstrap server.

[kFYatek]

The way to find out whether the security object refers to the SMS or to the UDP binding is via the content of the LwM2M Server URI.

How should a URI for SMS transport look like, then?

Note that Resource definitions table in section E.1 says that

The format of the CoAP URI is defined in Section 6 of RFC 7252.

and the relevant RFC section contains the wording:

If the host component is provided as an IP-literal or IPv4address, then the CoAP server can be reached at that IP address. If host is a registered name, then that name is considered an indirect identifier and the endpoint might use a name resolution service, such as DNS, to find the address of that host. The host MUST NOT be empty; if a URI is received with a missing authority or an empty host, then it MUST be considered invalid. The port subcomponent indicates the UDP port at which the CoAP server is located. If it is empty or not given, then the default port 5683 is assumed.

This does not seem to allow any means of specifying an address for a non-IP transport.

[dnav]

How should a URI for SMS transport look like, then?

See RFC 5724

[kFYatek]

Using RFC 5724 URIs would make some sense, although there seem to be several problems and incoherences with that approach:

• The Resource definition, as I mentioned above, explicitly refers to RFC 7252. RFC 5724 is also never mentioned in the document. The requirement to use RFC 5724 URIs would then look kind of like coming from nowhere.
• For Security object instances referring to the SMS transport, Resource 0 (URI) would be redundant with Resource 9 (LwM2M Server SMS Number). Which of them should take precedence? What if they are provisioned with different phone numbers in each of them?
• Resources 2 is specified as Mandatory, even though it is UDP-specific; it would then need to be set to some ignored value.

[kFYatek]

The support for DTLS over SMS is currently implemented in our client as follows:

• PSK secret key is stored in resource 8 (SMS Binding Secret Key(s)); the requirement for this resource to be "16-32-48 bytes" is ignored
• PSK identity is stored in resource 7 (SMS Binding Key Parameters); the requirement for this resource to be 6 bytes is ignored

While this is obviously a non-standard extension, I personally think it is a good idea. These resources are also used for configuring SMS security in the Secure Packet Structure mode (SMS Security Mode 2), and the two modes are mutually exclusive, so there is no conflict. It also seems to be in the spirit how the UDP security resources are defined, as resources 3 and 5 have slightly different semantics for PSK, RPK and certificate modes.

I have already shared this opinion with @mojanm during the TestFest, who seemed to agree with my argumentation.