CoAP-specific security schemes

[JKRhb]

Part of the current WG charter is the reorganization of security schemes so that the core specification will only contain generic security schemes, while protocol-specific security schemes are moved to the individual binding template documents. With this issue, I wanted to start discussing this process for CoAP, where at least one security scheme could be taken over from TD 1.1, while most other security schemes are currently missing and/or need to be formally specified.

In the following, I've created an initial list for collecting potential security schemes that can be discussed and expanded as we go along. Note that for some of these, a differentiation between the different CoAP URI schemes and the underlying transport protocols (e.g., UDP/DTLS vs. TCP/TLS) might be necessary. Some entries have once been included in drafts of the TD specification itself, before they got removed due to lack of implementations.

PskSecurityScheme

Can be taken over directly from the core TD specification. Applicable to both DTLS and TLS (and therefore also WebSockets).

Vocabulary Terms

(See section 5.3.3.9 of the TD 1.1 Recommendation.)

Vocabulary term	Description	Assignment	Type
cov:identity	Identifier providing information which can be used for selection or confirmation.	optional	string

Examples

{
  ...
  "securityDefinitions": {
    "scheme": "cov:PskSecurityScheme",
    "cov:identity": "Client_identity"
  },
  ...
}

CertSecurityScheme

This security scheme refers to the use of client certificates (cf. w3c/wot-thing-description#732) with DTLS/TLS in PKI mode that was previously defined in TD Editor's Drafts but got eventually removed. If we integrate this security scheme in the binding template document, we could consider renaming it to something like PkiSecurityScheme (or PKISecurityScheme) instead to be consistent with the security scheme for PSK.

PublicSecurityScheme

This security scheme refers to DTLS/TLS with raw public keys (RPKs, also see RFC 7250). It was also previously part of TD Editor's Draft but got removed in the end. If we choose to resurrect this one, we could rename it to RpkSecurityScheme. Similar to the security scheme above this one might only refer to client-side RPKs, but could also be used to indicate support for RPKs on the server side.

PoPSecurityScheme

This security scheme for authentication via Proof of Possession tokens was also once part of TD Editor's Drafts. I am not sure, though, whether we should bring this one back on its own – this might be a question of whether we have use cases that motivate the use of this security scheme.

OscoreSecurityScheme

There is currently no way to specify that a WoT consumer should interact with a Thing using OSCORE (Object Security for Constrained RESTful Environments, RFC 8613), so adding an OscoreSecurityScheme would be a great addition to the specification. Here, we need to figure out which fields we need to include and whether a description of the key exchange mechanism should be part of this security scheme or of separate companion security schemes (e.g., an EdhocSecurityScheme).

EdhocSecurityScheme

One of the companion security schemes for OSCORE could be for EDHOC (Ephemeral Diffie-Hellman Over COSE, RFC 9528), which has been created primarily as a key exchange mechanism for OSCORE but can, for example, also be used as part of a lightweight authorization framework for “enrolling” devices (see draft-ietf-lake-authz). I guess via a ComboSecurityScheme we could combine this security scheme with the one for OSCORE to indicate that it should be used as the key exchange mechanism, but this probably requires some discussion (I think the possible combinations of security schemes have not really been covered so far in general).

AceSecurityScheme

A security scheme for the ACE-OAuth (RFC 9200) framework has already been an informal part of the TD specification, but it would be great if it becomes a formally specified security scheme in the CoAP binding templates. As a lot of information call already discovered by the client from the resource server as part of the protocol flow (via the AS Request Creation Hints), the main benefit here is probably the association of scopes with affordances and maybe information regarding the profiles a resource server supports. However, as the TD can contain some of the information already, the resource server might be able to omit some of that information from its response, which could potentially have a security benefit. In any case, this security scheme probably needs some discussion, as there is also a certain degree of diversity involved via the different ACE-OAuth profiles (e.g., the DTLS profile, the OSCORE profile, and the OSCORE-EDHOC profile).

---

This concludes my initial list of security schemes for CoAP :) Feel free to comment if you want to discuss something or if something should be adjusted. I myself will gradually update the list to also include initial vocabulary terms and examples that we can further discuss.