Internet-Draft yang-edhoc-oscore February 2023
Marin-Lopez(Ed.), et al. Expires 1 September 2023 [Page]
Workgroup:
CORE Working Group
Internet-Draft:
draft-marin-yang-edhoc-oscore-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
R. Marin-Lopez(Ed.)
University of Murcia
G. Lopez-Millan
University of Murcia
L. Toutain
IMT
A. Fernandez
IMT

A YANG data model for SDN-based key management with EDHOC and OSCORE

Abstract

This document defines YANG data models which allow a Software-Defined Networking (SDN) Controller (Controller) using NETCONF, RESTCONF or CORECONF to provide configuration and monitoring Internet-of-Things devices (Things) that support Ephemeral Diffie-Hellman Over COSE (EDHOC) and/or OSCORE. In particular, a YANG data model defines the required configuration parameters to perform EDHOC between two Things (EDHOC case). Another YANG data model is to configure the OSCORE contexts directly into the Thing (OSCORE case). The service described in this document allows the configuration and monitoring of Things that supports EDHOC and OSCORE or only OSCORE by allowing a protected Thing-to-Thing communication based on CoAP.

This document focuses on providing YANG data models for configuring EDHOC or OSCORE. This allows OSCORE establishment with minimal intervention by the network administrator.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 1 September 2023.

Table of Contents

1. Introduction

Software-Defined Networking (SDN) is an architecture that enables administrators to directly program, orchestrate, control, and manage network resources through software. The SDN paradigm relocates the control of network resources to a centralized entity, namely the SDN Controller (from now on, the Controller). Controllers configure and manage distributed network resources and provide an abstracted view of the network resources to SDN applications. SDN applications can customize and automate the operations (including management) of the abstracted network resources in a programmable manner via this interface [RFC7149] [ITU-T.Y.3300] [ONF-SDN-Architecture] [ONF-OpenFlow].

Ephemeral Diffie-Hellman Over COSE (EDHOC, [I-D.ietf-lake-edhoc]) is a very compact and lightweight authenticated key exchange protocol designed for highly constrained devices. The main objective for EDHOC is to be a matching security handshake protocol to Object Security for Constrained RESTful Environments (OSCORE) [RFC8613], i.e., to provide authentication and session key establishment for IoT use cases such as those built on Constrained Application Protocol (CoAP) [RFC7252] involving 'Things' with embedded microcontrollers, sensors, and actuators. EDHOC reuses the same lightweight primitives as Object Security for Constrained RESTful Environments (OSCORE) [RFC8613], Concise Binary Object Representation (CBOR) [RFC8949] and CBOR Object Signing and Encryption (COSE) [RFC9052], and specifies the use of CoAP, but is not bound to a particular transport protocol.

OSCORE is a method for application-layer protection (integrity and confidentiality) of CoAP, using COSE. OSCORE provides end-to-end protection between Things communicating using CoAP or CoAP-mappable HTTP.

With the growth of SDN-based scenarios where network resources are deployed and managed in an autonomous and dynamic manner, a mechanism to configure EDHOC and OSCORE from a centralized entity (the Controller) may become more relevant in the industry. Nowadays, this security association management has been standardized with IKEv2 and IPsec [RFC9061], even for contrained devices.

This document defines two YANG data models for two different cases: EDHOC case, where the Thing supports EDHOC (and OSCORE); and OSCORE case, where the Thing only supports OSCORE and not EDHOC. An external entity, such as the Controller can configure parameters into the EDHOC and/or OSCORE implementation that allow protecting CoAP messages between Things.

In summary, the objectives of this document are:

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. SDN-based key management for EDHOC and OSCORE

As mentioned in Section Section 1, two cases are considered, depending on whether the Thing ships both EDHOC and OSCORE, or only OSCORE: the EDHOC case and the OSCORE case, respectively.

3.1. EDHOC Case: EDHOC+OSCORE in the Things

In this case, the Thing implements EDHOC and OSCORE. The Controller is in charge of managing and applying EDHOC connection information, determining which Thing will act as EDHOC Initiator or EDHOC responder; identifying the resources to be protected with OSCORE, deriving and delivering EDHOC identities, credentials, etc.) and other EDHOC configuration parameters (e.g., cryptographic algorithms) to the Thing, necessary for EDHOC negotiation.

With this information, the EDHOC implementation can operate to establish the OSCORE contexts. The Administrator establishes the general security requirements (through the Northbound Interface), and the Controller translates these requirements into EDHOC configuration that will be installed into the Thing (through the Southbound Interface). With that information, the device can just run EDHOC with other Things to establish OSCORE contexts (when the access to the resource mandates so). Figure 1 shows the different layers and corresponding functionality.

Key Management System Administrator Northbound Interface EDHOC Configuration SDN Generation Controller Southbound Interface (CORECONF,RESTCONF,...) EDHOC Thing OSCORE
Figure 1: EDHOC Case: EDHOC+OSCORE in the Thing

To support this case, a YANG data model for EDHOC configuration data and state data needs to be defined for the Southbound Interface (see Section 6).

3.2. OSCORE case: only OSCORE in the Things

In this case, the Thing does not deploy EDHOC and, therefore, the Controller has to provide the OSCORE contexts and to manage them.

As shown in Figure 2, when an Administrator enforces protection policies through the Northbound Interface, the Controller translates these requirements directly into OSCORE contexts, which are installed in the Thing.

Key Management System Administrator Northbound Interface OSCORE SDN contexts generation Controller s Southbound Interface (CORECONF,RESTCONF,...) OSCORE Thing
Figure 2: OSCORE Case: only OSCORE (No EDHOC) in the Thing

In order to support the OSCORE case, a YANG data model for OSCORE configuration data and state data MUST be defined for the Southbound Interface (see Section 6). Specifically, the OSCORE case assumes that the Controller has to perform some security functions that EDHOC typically does, specifically the OSCORE context generation and management.

4. EDHOC case vs OSCORE case

In principle, the EDHOC case offloads the Controller the tasks of monitoring, generating and configuring specific OSCORE contexts, including cryptographic material generation. However, the Things require more resources, such as memory for the EDHOC implementation and computation because it involves Diffie-Hellman (DH) exchanges. Beside, if Things run EDHOC, the data plane network traffic between Things increases due to the additional EDHOC protocol exchange, so it should be taken in account in very constrained data plane networks.

Alternatively, the OSCORE case may benefit of the deployment in more resource-constrained Things, because EDHOC does not need to be performed between two Things. Additionally, the network data plane is not overloaded with the EDHOC traffic. On the contrary, the complexity of creating and managing OSCORE contexts, including cryptographic material, is shifted to the Controller since EDHOC is not in the Thing. As a consequence, this may result in a more complex implementation in the Controller side in comparison with the EDHOC case. This complexity may create some scalability and performance issues when the number of Things is high.

Nevertheless, literature around SDN-based network management using a centralized controller is aware of scalability and performance issues, and solutions have been already provided and discussed (e.g., hierarchical controllers, having multiple replicated controllers, dedicated high-speed management networks, etc.).

Another way to reduce the overhead and the potential scalability and performance issues in the Controller is to apply the EDHOC case described in this document since the OSCORE contexts are managed between Things without the involvement of the Controller, except by the initial configuration provided.

In terms of security, the EDHOC case provides better security properties than the OSCORE case, as discussed in Section Section 8. The main reason is that the Things generate the session keys and not the Controller.

5. Entities interaction

5.1. EDHOC case overview

Figure 3 describes the application of the EDHOC case when a CoAP exchange needs to be protected in the path between Thing A and Thing B, and Things support EDHOC and OSCORE:

Key Management System | (1) Security Northbound Protection Policy Interface Controller (2) Translate into CORECONF/ EDHOC Conf RESTCONF Southbound Interface (3) | | (4) EDHOC EDHOC EDHOC OSCORE (5)CoAP+OSCORE OSCORE CoAP Client CoAP Server Thing A Thing B
Figure 3: EDHOC case overview
  1. The network administrator establishes the general security protection policies, including security policies for protecting resources between A and B. The Controller looks for the involved Things (A and B).
  2. The Controller translates these policies into EDHOC configuration for the specific Things (connection identifiers, authentication credentials, cipher suites, authorization data, etc.), following the requirements described in [I-D.ietf-lake-edhoc][I-D.ietf-core-oscore-edhoc].
  3. The Controller sends these EDHOC configurations to both Thing A and Thing B. Due to one may have the role of EDHOC responder (e.g. Thing B) and the other the role of EDHOC initiator (e.g. Thing A), it is advised to send configurations first to the EDHOC responder and, once it is successfully finished, to the EDHOC initiator. If some of the operations described above fail (e.g., Things A reports an error when the Controller is trying to install the EDHOC configuration), the Controller MAY perform a rollback operation by deleting any previous EDHOC configuration that had been successfully installed in the other Thing (e.g. Thing B) and stop the process. Note that the Controller MAY retry several times before giving up. NOTE: It is assumed that a security association has been previously setup between the Controller and each Thing.
  4. If the previous steps are successful, the EDHOC initiator can start the EDHOC exchange. It is worth noting that EDHOC may be started by the initiator either only when the traffic need to be protected or just after the EDHOC configuration is applied in the Thing, instructed by the Controller.
  1. After completion of the EDHOC exchange, OSCORE contexts are created in Things A and B, and the CoAP traffic can be protected. Finally, the Controller may associate a lifetime to renew OSCORE contexts, as described in Section 5.3.

5.2. OSCORE case overview

Figure 4 describes the application of the OSCORE case when a CoAP exchange needs to be protected in the path between Thing A and Thing B, and Things support OSCORE, but does not support EDHOC:

Key Management System | (1) Security Northbound Protection Policy Interface Controller (2) Translate into CORECONF/ OSCORE Contexts RESTCONF Southbound Interface (3) | | OSCORE (4)CoAP+OSCORE OSCORE CoAP Client CoAP Server Thing A Thing B
Figure 4: OSCORE case overview
  1. The network administrator establishes the general security protection policies, including security policies for protecting resources between A and B. The Controller looks for the involved Things (A and B).
  2. The Controller translates these policies into specific OSCORE contexts (Common, Sender and Recipient) for the specific CoAP service. Following the requirements described in [RFC8613]. It generates the cryptographic keys and salts using random values.
  3. The Controller sends these OSCORE contexts to both Thing A and Thing B. Due to one may have the role of CoAP server (e.g. Thing B) and the other the role of CoAP client (e.g. Thing A), it is advised to send the contexts first to the CoAP server and, once it is successfully finished, to send the contexts to the CoAP client. If some of the operations described above fail (e.g., Things A reports an error when the Controller is trying to install the OSCORE contexts), the Controller MAY perform a rollback operation by deleting any OSCORE context that had been successfully installed in the other Thing (e.g. Thing B) and stop the process. Note that the Controller MAY retry several times before giving up.
  4. If the steps 1 to 3 are successful, the CoAP exchanges between Thing A and Thing B are protected with OSCORE. It is worth mentioning that the Controller associates a lifetime to the new OSCORE contexts. When this lifetime expires, the Controller will update the OSCORE contexts.

5.3. Renewal of the OSCORE security context

In this version of the document we have only considered four ways to configure the renewal of the OSCORE contexts. Two of them are possible for the EDHOC case and another two for the OSCORE case.

  • EDHOC case:

    • OSCORE contexts are renewed after a full EDHOC re-run. The Controller can configure the Thing to perform the EDHOC re-run each certain time (reauth time).
    • An SDN-based renewal where the Controller sends a context to the Things used for the EDHOC_KeyUpdate (Appendix I in [I-D.ietf-lake-edhoc]). With this context, the Things can call EDHOC_KeyUpdate to generate a new PRK and, therefore, new keys for the OSCORE context.
  • OSCORE case:

    • An SDN-based renewal where the Controller is in charge of sending new OSCORE contexts periodically following an internal policy (e.g. each 8 hours). The cryptographic material generated for the OSCORE contexts is completely fresh and separated from previous contexts.
    • The mechanism explained in OSCORE [RFC8613] (section B.2. Security Context Derived Multiple Times) where the Controller only sets the length of the nonces R1, R2, and R3 in each Thing.

Editor's note: Future updates of this document will include extensions to the model to support OSCORE KUDOS. At this point, the model assumes that the Controller is in charge or renewing the OSCORE contexts periodically following an internal policy.

5.4. Thing to non constrained devices communication

Although the architecture described in this document insists on the communication between Things, it is also common the communication between a Thing and a non-so constrained device. Two main situation are envisaged:

  • If both entities (the Thing and the non-so constrained device) are under the management of the Controller. The solution described here applies with no change. The only comment here is that the protocol for carrying the configuration to the non-so constrained device can be less constrained (e.g. NETCONF or RESTCONF).
  • Only the Thing is managed by the Controller, then it is assumed that the non-so constrained device is configured somehow (out of scope this document) and the Controller only configures the Thing to communicate securely with this non-so constrained device. The YANG data models are still applicable in this case.

5.5. Thing bootstrapping, registration and discovery

Initial security setup (bootstrapping) for a Thing refers to any process that takes place before a device can become operational [I-D.irtf-t2trg-secure-bootstrapping]. The initial security setup process, among other processes, involves network discovery and selection, access authentication, configuration of necessary credentials and parameters.

Thus, bootstrapping is the process to provide the Thing with the required information (i.e. credentials) to authenticate to the IoT network. We assume that the Thing is preconfigured with the required information and credentials to carry out the bootstrap process. It enables the Thing to run an authenticated registration process with the Controller in order to enable the management in the particular domain under the Controller.

The assumption in this document is that, before a Thing can operate in the IoT network, it MUST be registered in the Controller. In this way, when the Thing starts, it establishes a security association with the Controller. This security association, which can be based on DTLS, EDHOC+OSCORE, or only OSCORE, allows the protected exchange of information between the Controller and the Thing. After the bootstrapping process, the Thing is valid for joining the Controller's security domain.

The Controller MUST discover certain capabilities of this Thing, such as the supported cryptographic suites, the authentication method, the support of the EDHOC case and/or the OSCORE case, resources, network addressing, etc. This information is incorporated into a list of Things under its control.

The registration and discovery processes are out of the scope of this document.

5.6. Thing state loss

If one of the Thing restarts, it may lose the OSCORE state (affected Thing). By default, the Controller can assume that all the state has been lost and, therefore, it will have to send new configuration information for EDHOC to the affected Thing in the EDHOC case, and new OSCORE contexts in the OSCORE case.

In both cases, the Controller is aware of the affected Thing (e.g., by using some keep alive mechanism such as the "CoAP Ping" or because the TCP connection is broken with the affected Thing). The Controller keeps a list of Things registered and can determine what are the affected ones.

In the EDHOC case, the Controller may need to configure the affected Thing with the new EDHOC information. Alternatively, EDHOC configuration MAY be made permanent between Thing reboots without compromising security by means of non-volatile memory in the Thing. This way, each time an Thing reboots, it will use that configuration for each rebooting. It would imply avoiding contact with the Controller. Finally, the Controller may also need to send new parameters (e.g., a new authentication credentials, etc.) to the Things that had security associations with the affected Thing.

In the OSCORE case, the Controller SHOULD delete the old OSCORE contexts in the non-failed Things established with the affected Thing. Once the affected Thing restarts, the Controller MUST take the necessary actions to reestablish the OSCORE contexts between the failed Thing and those others having security associations with the affected one. How the Controller implements an algorithm for managing a potential Thing state loss is out of the scope of this document.

6. YANG Data Models

In order to support the EDHOC case and the OSCORE case, YANG data models are provided for the different parameters and values that must be configured to manage EDHOC and OSCORE. Specifically, the EDHOC case requires modeling EDHOC configuration parameters such as Thing's identity and authentication information, and when to run EDHOC, besides parameters to define how the OSCORE context should be established. The OSCORE case requires configuration YANG data models for the definition of OSCORE contexts. Two modules have been defined: ietf-core-edhoc (Section 5.2, case EDHOC), and ietf-core-oscore (Section 5.3, case OSCORE).

6.1. EDHOC case

6.1.1. Data model overview

The YANG data model defines the configuration data for EDHOC. The model provides four lists: 'auth-entry', 'connection', 'target resource' and 'local resource'.

  • The list 'auth-entry' contains a set of leafs that contain authentication information for running EDHOC in this Thing (such as Thing credential identity, preferred authentication method and public and private key credentials). Each Thing may be configured with several 'auth-entry' elements. Each element in the list may be used by one or more 'connections' defined to other Things.
  • The list 'connection' contains a list of containers and leafs that specifies different connections between this Thing (local) and a peer (remote), for example, another Thing. This list specifies the local credentials that will be used for this Thing with the remote peer (with a reference to an entry in the list 'auth-entry'), and the credentials that will be required to authenticate the remote peer. For the local Thing, it also specifies the connection identifier, cipher suites, and authorization data depending on the role defined by this Thing (EDHOC initiator or responder). Additionally, other EDHOC parameters may be defined, such as EDHOC key confirmation option, the automatically establishment of an OSCORE context between local and remote Things, or rekey management options and lifetimes.
  • The list 'target-resource' stores policies (bypass, discard, protect) related with the target resource (URI) that this Thing can access. In case OSCORE protection is required, an entry in this list defines a reference to a list 'connection' entry to run EDHOC.
  • The list 'local-resource' stores policies related with the local resources provided by this Thing.
module: ietf-core-edhoc rw edhoc rw auth-entry* [name] rw name string rw id-cred-x binary rw auth-method? auth-method-t rw cred-x binary rw private-key binary rw connection* [name] rw name string rw local rw autostartup? boolean rw auth-cred-ref string rw c-x? binary rw suites-x? binary rw ead-x rw ead-a? binary rw ead-b? binary rw remote rw id-cred-x binary rw auth-method? auth-method-t rw cred-x binary rw key-confirmation? boolean rw set-oscore? boolean rw key-update-context? binary rw reauth-time rw soft? uint32 rw hard? uint32 rw target-resource* [target] rw target inet:uri rw policy? policy-t rw conn-ref? string rw local-resource* [local] rw local inet:uri rw policy? policy-t rw conn-ref? string
Figure 5: EDHOC data model tree

NOTE: Although EDHOC is independent of OSCORE, the EDHOC model considers the fact that OSCORE will be used after running EDHOC. In any case, the model has incoporated a flag 'set-oscore' when EDHOC is configured and OSCORE is not required (e.g. for example, EDHOC could be used to derive key material to protect the link-layer). Nevertheless, the list of policies ('target-resource' and 'local-resource') defined in the model only considered the case when the access with CoAP to a particular URI is required. To include additional uses cases this policy should be extended to consider, for example, MAC addresses or IP addresses (TBD).

6.1.2. YANG module

The detailed YANG module for the EDHOC case is described in Appendix A.

6.1.3. Example usage

Appendix B shows an example of an EDHOC case configuration.

6.2. OSCORE case

This version includes the YANG data model taking into account the information in OSCORE. The model contains three main lists: 'context', 'target-resource', 'local-resource'.

  • The list 'context' stores the OSCORE contexts in this Thing. Each node in the list 'context' contains three specific contexts: common ('common-ctx'), sender ('sender-ctx') and recipient ('recipient-ctx'). 'common-ctx' defines the common context ID, authentication encryption algorithms, key derivation function, master key and master salt used by this OSCORE context. 'sender-ctx' defines the sender context ID, and 'recipient-ctx' defines the recipient context ID and the replay-window value, as described in [RFC8613]. For each OSCORE context this container also defines how the context renew has to be carried out by the Things. As described in section Section 5.3, two options are included in this model, SDN-based and OSCORE-based.
  • The list 'target-resource' stores policies (bypass,discard,protect) related with the target resource that this Thing can access. In case of protection with OSCORE, a node in the list has a reference to a node in the list 'context'.
  • The list 'local-resource' stores policies related with the local resources provided by this Thing, acting as server of a particular resource.
module: ietf-core-oscore rw oscore rw context* [id-entry] rw id-entry binary rw common-ctx rw id? binary rw aead-alg? uint32 rw hkdf-alg? uint32 rw master-key? binary rw master-salt? binary rw sender-ctx rw id? binary rw recipient-ctx rw id? binary rw replay-window? uint64 rw renew-ctx rw (method)? :(multiple-times) rw ctx-derivation rw r1-length? uint64 rw r2-length? uint64 rw r3-length? uint64 :(sdn-based) rw sdn-based? empty rw target-resource* [target] rw target inet:uri rw policy? policy-t rw id-entry-ref? binary rw local-resource* [local] rw local inet:uri rw policy? policy-t rw id-entry-ref? binary
Figure 6: OSCORE data model tree

6.2.1. YANG module

The detailed YANG module for the EDHOC case is described in Appendix C.

6.2.2. Example usage

Appendix D shows an example of an EDHOC case configuration.

7. IANA Considerations

TBD

8. Security Considerations

First of all, this document shares all the security issues of SDN that are specified in the Security Considerations sections of [ITU-T.Y.3300] and [RFC7426].

On the one hand, it is important to note that there MUST exist a security association providing confidentiality and integrity between the Controller and the Things to protect the critical information (cryptographic keys, configuration parameter, etc.) exchanged between these entities. The nature of and means to create that security association is out of the scope of this document (i.e., it is part of device provisioning or bootstrapping).

On the other hand, the default policy MUST be to drop (DISCARD) CoAP messages to prevent information leaks. This default policy MUST be preconfigured in the non-volatile memory in the Thing before the Thing contacts the Controller. Moreover, the non-volatile memory MUST be also preconfigured with the required ALLOW policies that allow the Thing and the Controller to communicate each other. This preconfiguration step is not carried out by the Controller but by some other entity before the Thing deployment. In this manner, when the Thing starts/reboots, it will always first apply the configuration in the non-volatile memory before contacting the Controller.

Finally, this section is divided in two parts in order to analyze different security considerations for both cases: Thing with EDHOC+OSCORE (EDHOC case) and Thing without EDHOC (OSCORE case). In general, the Controller, as typically happens in the SDN paradigm, is a target for different type of attacks, see [SDNSecServ] and [SDNSecurity]. Thus, the Controller is a key entity in the infrastructure and MUST be protected accordingly. In particular, the Controller will handle cryptographic material; thus, the attacker may try to access this information. The impact is different depending on the EDHOC case or the OSCORE case.

8.1. EDHOC case

In the EDHOC case, the Controller MAY send EDHOC credentials (public/private keys, certificates, etc.) to the Things using the security association between the Controller and Things. The Controller MUST NOT store the EDHOC credentials after distributing them. Moreover, the Controller MUST NOT allow the reading of these values once they have been applied into the Thing (i.e., write-only operations). One option is to always return the same value (i.e., all 0s) if a read operation is carried out.

If the attacker has access to the Controller during the period of time that key material is generated, it might have access to the key material. Since these values are used during authentication in EDHOC, it may impersonate the affected Things. Several recommendations are important:

  • In the EDHOC case, the Controller MAY generate both public key and private key for the authentication process. In such a case, the Controller MUST remove the associated private key immediately after distributing them to the Things.
  • Alternatively, the Thing MAY generate the private key and export only the public key to the Controller. How the Thing generates these cryptographic materials (public key/ private keys) and exports the public key is out of scope of this document.
  • If certificates are used, the Thing MAY generate the private key and export the public key for certification to the Controller. How the Thing generates these cryptographic material (public key/ private keys) and exports the public key is out of scope of this document.

8.2. OSCORE case

In the OSCORE case, the Controller sends the OSCORE contexts that includes the session keys required for integrity and encryption. The Controller MUST NOT store these keys after distributing them. Moreover, the Thing receiving the OSCORE context MUST NOT allow the reading of these keys by any other entity (including the Controller itself) once they have been applied (i.e., write-only operations) into the Thing. Nevertheless, if the attacker has access to the Controller during the period of time that key material is generated, it may obtain these values. In other words, the attacker might be able to observe the CoAP traffic and decrypt, or even modify and re-encrypt, the CoAP exchanges between Things.

Finally, the security association between the Controller and the Things MUST provide, at least, the same degree of protection as the one achieved by the session keys used in the OSCORE contexts. In particular, the security association between the Controller and the Things MUST provide forward secrecy if this property is to be achieved in the OSCORE contexts that the Controller configures into the Things. Similarly, the encryption algorithms used in the security association between the Controller and the Things MUST have, at least, the same strength (minimum strength of a 128-bit key) as the algorithms used to establish the OSCORE contexts.

9. References

9.1. Normative References

[I-D.ietf-core-comi]
Veillette, M., Van der Stok, P., Pelov, A., Bierman, A., and I. Petrov, "CoAP Management Interface (CORECONF)", Work in Progress, Internet-Draft, draft-ietf-core-comi-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-11>.
[I-D.ietf-core-oscore-edhoc]
Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and G. Selander, "Profiling EDHOC for CoAP and OSCORE", Work in Progress, Internet-Draft, draft-ietf-core-oscore-edhoc-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-edhoc-06>.
[I-D.ietf-lake-edhoc]
Selander, G., Mattsson, J. P., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in Progress, Internet-Draft, draft-ietf-lake-edhoc-19, , <https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-19>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC6241]
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/info/rfc6241>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8613]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, , <https://www.rfc-editor.org/info/rfc8613>.

9.2. Informative References

[I-D.ietf-cose-cbor-encoded-cert]
Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 Certificates)", Work in Progress, Internet-Draft, draft-ietf-cose-cbor-encoded-cert-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-05>.
[I-D.irtf-t2trg-secure-bootstrapping]
Sethi, M., Sarikaya, B., and D. Garcia-Carrillo, "Terminology and processes for initial security setup of IoT devices", Work in Progress, Internet-Draft, draft-irtf-t2trg-secure-bootstrapping-03, , <https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-secure-bootstrapping-03>.
[ITU-T.Y.3300]
"Y.3300:Framework of software-defined networking", , <https://www.itu.int/rec/T-REC-Y.3300/en>.
[ONF-OpenFlow]
"OpenFlow Switch Specification, Version 1.4.1 (Wire Protocol 0x05)", , <https://opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.4.1.pdf>.
[ONF-SDN-Architecture]
"SDN architecture, Issue 1", , <https://www.opennetworking.org/wp-content/uploads/2013/02/TR_SDN_ARCH_1.0_06062014.pdf>.
[RFC5280]
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/info/rfc5280>.
[RFC5869]
Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, , <https://www.rfc-editor.org/info/rfc5869>.
[RFC7149]
Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, , <https://www.rfc-editor.org/info/rfc7149>.
[RFC7252]
Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, , <https://www.rfc-editor.org/info/rfc7252>.
[RFC7426]
Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, , <https://www.rfc-editor.org/info/rfc7426>.
[RFC8040]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/info/rfc8040>.
[RFC8392]
Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, , <https://www.rfc-editor.org/info/rfc8392>.
[RFC8949]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/info/rfc8949>.
[RFC9052]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/info/rfc9052>.
[RFC9061]
Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-Garcia, "A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)", RFC 9061, DOI 10.17487/RFC9061, , <https://www.rfc-editor.org/info/rfc9061>.
[SDNSecServ]
Scott-Hayward, S., Callaghan, G. O., and P. Sezer, "SDN Security A Survey", , <https://doi.org/10.1109/SDN4FNS.2013.6702553>.
[SDNSecurity]
Kreutz, D., Ramos, F., and P. Verissimo, "Towards secure and dependable software-defined networks", , <https://doi.org/10.1145/2491185.2491199>.

Appendix A. YANG data model for EDHOC case

module ietf-core-edhoc {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-core-edhoc";
  prefix edhoc;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types.";
  }

  import ietf-netconf-acm {
    prefix nacm;
    reference
      "RFC 8341: Network Configuration Access Control
                 Model.";
  }

  organization
    "IETF CORE Working Group";
  contact
    "WG Web:  <https://datatracker.ietf.org/wg/core/>
     WG List: <mailto:core@ietf.org>

     Author: Rafael Marin-Lopez
               <mailto:rafa@um.es>
     Author: Gabriel Lopez-Millan
               <mailto:gabilm@um.es>
    ";
  description
    "This module contains the EDHOC Case YANG model for the
     SDN-based Key Management for EDHOC.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
     'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
     document are to be interpreted as described in BCP 14
     (RFC 2119) (RFC 8174) when, and only when, they appear
     in all capitals, as shown here.

     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (http://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; see
     the RFC itself for full legal notices.";

  revision 2022-11-28 {
    description
      "Initial version. The YANG data model defines the
      configuration data for EDHOC. The model provides four lists
      'auth-entry', 'connection', 'target resource' and 'local
      resource'.

      The list 'auth-entry' contains a
      set of nodes that contain authentication information for
      EDHOC run for this local Thing.

      The list 'connection' contains a set of nodes that specifies
      different connections between this Thing and a peer Thing.
      This list specifies what credentials will be used for the
      local Thing (with a
      reference to an entry in the list 'auth-entry' and the
      credential that will be required to authenticate the remote
      Thing).

      The list 'target-resource' stores policies
      (bypass,discard,protect) related with the target resource
      that this Thing can access. In case of protection, a node in
      the list has a reference to a node in the list 'connection'
      to run EDHOC.

      The list 'local-resource' stores policies related with the
      local resources provided by this Thing.";

    reference
      ".";

  }

  typedef auth-method-t {
    type enumeration {

      enum signature-key {
        description
          "Authentication Key is a Signature Key.";
      }
      enum static-dh-key {
        description
          "Authentication Key is a Static DH Key.";
      }

    }
    description
      "The authentication method can include Signature Key or
      Static Diffie-Hellman Key.";
  }

  typedef policy-t {
    type enumeration {
      enum protect {
        description
          "PROTECT the traffic with OSCORE.";
      }
      enum bypass {
        description
          "The CoAP resource does not require
          OSCORE protection";
      }
      enum discard {
        description
          "The CoAP message to a resource is
          discarded.";
        }
      }
      description
        "The policy applicable to access a CoAP resource.
        There are three possible values: BYPASS
        (the CoAP message is unprotected), PROTECT
        (the CoAP message MUST be protected with OSCORE),
        and DISCARD (the CoAP message is discarded).";
  }

  grouping auth-cred-grouping {

    leaf id-cred-x {
      type binary;
      mandatory true;
      description
        "ID_CRED_X, X=I or R.
        COSE header maps and contains one or more
        COSE header parameters";
    }

    leaf auth-method {
      type auth-method-t;
      default "signature-key";
      description
        "Type of authentication method
        (signature key, static DH key).";
    }

    leaf cred-x {
      type binary;
      mandatory true;
      description
        "X.509 certificates [RFC5280], C509 certificates
        [I-D.ietf-cose-cbor-encoded-cert], CWTs [RFC8392]
        and CWT Claims Sets (CCS) [RFC8392]. Static DH Public
        and RPK are also included here. If this information is
        associated to the other peer , it contains the information
        required to verify the Signature_or_MAC field.";
    }
    description
      "This grouping contains the ID_CRED_X for a particular
      entity X=I or X=R and authentication method and the public
      information of the CRED_X information about the
      authentication credential";

  } /*grouping auth-cred-grouping*/

  container edhoc {

    description
      "EDHOC configuration for a Thing. It includes authentication
      credentials for this Thing. EDHOC connection information that
      is a represented with a list of 'connection'. Each connection
      contains information about the remote EDHOC peer and the
      information to authentication against that node.";

    list auth-entry {
      key "name";
      ordered-by user;
      description
        "Authentication information entry for the Thing.
        It is a list of entries ordered by the
        Controller, and each entry is
        unequivocally identified by a name.";

      leaf name {
        type string;
        description
          "Unique name to identify this entry.";
      }

      uses auth-cred-grouping;

      leaf private-key {
        nacm:default-deny-all;
        type binary;
    mandatory true;
        description
          "The private key used for this auth-entry associated to
          the public key contained in the Authentication
          Credential. This value can be set either by the
          Controller or the node can generate it so that
          it is not known by the Controller.";
      }
    } /*list auth-entry*/

    list connection {

      key "name";
      ordered-by user;
      description
        "List of connections defined between and the Thing A
        (local peer) and B (remote peer). The list is ordered
        by the Controller, and each entry is
        unequivocally identified by a name.";

      leaf name {
        type string;
        description
          "Unique name to identify this entry.";
      }

      container local {

        leaf autostartup {
          type boolean;
          default 'false';
          description
            "True: the EDHOC implementation starts immediately
            after setting the configuration of this connection.";
        }

        leaf auth-cred-ref {
          type string;
          mandatory true;
          description
            "Local peer authentication information.
            This node points to a specific entry in
            the list 'auth-entry' where the authentication
            information about this peer is stored.
            It MUST match a 'name' in the list.";
        }

        leaf c-x {
          type binary;
          description
            "Connection identifier. This value is optional since,
            in general, the connection identifier can be generated
            by the node.";
        }

        leaf suites-x {
          type binary;
          description
            "Array of cipher suites which the peer acting as
            Initiator or Responder supports. In case the node acts
            as Initiator (X=I) the array is in order of preference,
            the first cipher suite in network byte order is the
            most preferred by the Initiator, the last is the one
            selected by the Initiator for this session. The order
            of the cipher suites in SUITES_R has no significance.
            If the most preferred cipher suite is selected then
            SUITES_I contains only that cipher suite and is encoded
            as an int. Since the controller has information
            about the nodes in the connection can set the suitable
            cipher suite to avoid any crypto suite negotiation.";
        }

        container ead-x {
          leaf ead-a {
            type binary;
            description
              "This value contains the EAD 1 when the peer acts
              as the initiator or EAD 2 when it is the responder.";
          }

          leaf ead-b {
            type binary;
            description
              "This value is EAD 3 when the peer is the initiator
              or EAD 4 when it is the responder.";
          }
          description "To set the EAD in EDHOC (if any).";
        }

        description
          "Local node authentication information.";

      } /*container local*/

      container remote {
        uses auth-cred-grouping;
        description
          "Remote node authentication information.";
      } /*container remote*/

      leaf key-confirmation {
        type boolean;
        default 'false';
        description
          "True: message 4 will be sent (if the node is acting as
         initiator or it has to be received is if the initiator)";
      }

      leaf set-oscore {
        type boolean;
        default 'true';
        description
          "True when after EDHOC we require to establish an
          OSCORE Security Context.";
      }

      leaf key-update-context {
        type binary;
        description
          "The controller sets a context so that EDHOC-KeyUpdate
          can be performed. Each time this value is update the
          EDHOC-KeyUpdate is performed.";
        reference
          "Appendix I. Ephemeral Diffie-Hellman Over COSE (EDHOC)
          draft-ietf-lake-edhoc-19.";
      }

      container reauth-time {
        leaf soft {
          type uint32;
          units "seconds";
          default "0";
          description
            "Soft lifetime. After reaching this time the EDHOC
            re-authentication will start.";
        }
        leaf hard {
          type uint32;
          units "seconds";
          default "0";
          description
            "Hard lifetime. After reaching this time the EDHOC
            session will be removed.";
        }
        description ".";

      } /*container reauth-time*/
    } /* list connection */

    list target-resource  {

      description
        "This list contains the resources that this peer
        (acting as CoAP client) will access and that requires
        OSCORE protection (depending on the policy) in the other
        peer (acting as a CoAP server). They may be discovered by
        some other means by the Thing but installing them allows
        the device to protect immediately the CoAP
        message. The list is ordered by the controller. An node in
        the list is evaluated before the next node in the list.
        If there is a match the evaluation is stopped and the
        policy applied. That is nodes at the beginning of the list
        has more priority that final nodes.";

      key "target";
      ordered-by user;

      leaf target {
        type inet:uri;
        description
          "URI to the target resource to be protected with this
          OSCORE Sender Context. If the URI is an empty string it
          means ANY";
      }

      leaf policy {
        type policy-t;
        default 'protect';
        description
          "The policy applied to this resource. Default policy is
          protect. If there is no common context to protect the
          CoAP message is discarded. If the list is empty is not
          possible to access to any resource.";
      }

      leaf conn-ref {
        when "../policy = 'protect'";
        type string;
        description
          "Byte string used to identify the connection in the list
          'connection' that must be used to protect this message.
          The Thing will act as EDHOC initiator. If the EDHOC
          session is already set and cryptographic material is
          available the message will be protected.";
      }
    } /*list target-resources*/

    list local-resource {

      description
        "This list contains the resources that may require
        protection (depending of the policy) in this peer (acting
        as a CoAP server).";

      key "local";
      ordered-by user;

      leaf local {
        type inet:uri;
        description
          "URI of the local resources to be protected with
          this OSCORE Recipient Context.";
      }

      leaf policy {
        type policy-t;
        default 'protect';
        description
          "The policy applied to this resource. Default policy is
          protect. If there is no common context to protect the
          CoAP message is discarded.";
      }

      leaf conn-ref {
        when "../policy = 'protect'";
        type string;
        description
          "Byte string used to identify the connection in the list
          'connection' that must be used to protect this resource.
          The Thing will act as EDHOC responder. If the EDHOC
          session is already set and cryptographic material
          is available the message will be protected.";
      }
    } /*list local-resource*/
  } /* container edhoc */
} /* module ietf-core-edhoc */

Appendix B. EDHOC case example usage

This example shows an XML representation of the configuration sent by the SDN Controller to establish an EDHOC-derived OSCORE context to Thing 't1' using "signature-key" authentication (RSA) when accessing the resource "coap://2001:db8:cafe:123::200/res1". (Some values are simplified for brevity with "base64encodedvalue==").

SDN Controller Southbound Interface t1 EDHOC/OSCORE t2 /res1 :100 :200 (2001:db8:cafe:123:/64)
<edhoc xmlns="urn:ietf:params:xml:ns:yang:ietf-core-edhoc" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <auth-entry> <name>auth_entry_t1</name> <id-cred-x>base64encodedvalue==</id-cred-x> <private-key>base64encodedvalue==</private-key> <auth-method>signature-key</auth-method> <cred-x>base64encodedvalue==</cred-x> </auth-entry> <connection> <name>edhoc_conn_t1_t2</name> <local> <autostartup>true</autostartup> <auth-cred-ref>auth_entry_t1</auth-cred-ref> <c-x>Mzc=</c-x><!--37 <suites-x>MDI=</suites-x><!--02 <ead-x>\ <ead-a>MDE=</ead-a><!--01 <ead-b>MDI=</ead-b><!--02 </ead-x> </local> <remote> <id-cred-x>base64encodedvalue==</id-cred-x> <cred-x>base64encodedvalue==</cred-x> </remote> <key-confirmation>true</key-confirmation> <set-oscore>true</set-oscore> <key-update-context/> <reauth-time/> </connection> <target-resource> <target>coap://2001:db8:cafe:123::200/res1</target> <policy>protect< policy> <conn-ref>edhoc_conn_t1_t2</conn-ref> </target-resource> </edhoc>

Appendix C. YANG data model for OSCORE case

module ietf-core-oscore {

  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-core-oscore";
  prefix oscore;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types.";
  }

  import ietf-netconf-acm {
    prefix nacm;
    reference
      "RFC 8341: Network Configuration Access Control
                 Model.";
  }

  organization
    "IETF CORE Working Group";
  contact
    "WG Web:  <https://datatracker.ietf.org/wg/core/>
     WG List: <mailto:core@ietf.org>

     Author: Rafael Marin-Lopez
              <mailto:rafa@um.es>
     Author: Gabriel Lopez-Millan
              <mailto:gabilm@um.es>

    ";
  description
    "Data model for OSCORE case (RFC 8613) in the SDN-based
     OSCORE flow protection service.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
     'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
     document are to be interpreted as described in BCP 14
     (RFC 2119) (RFC 8174) when, and only when, they appear
     in all capitals, as shown here.

     Copyright (c) 2021 IETF Trust and the persons
     identified as authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD
     License set forth in Section 4.c of the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of ; see
     the RFC itself for full legal notices.";

  revision 2022-11-28 {
    description
      "Initial version. This version only includes the YANG Data
      model taking into account the information in Object
      Security for Constrained RESTful Environments (OSCORE).

      The model contains three main lists: context,
      targer-resource and local-resource.
      The list 'context' stores the OSCORE context in this
      Thing. Each node in the list 'context' contains three
      contexts: common ('common-ctx'), sender ('sender-ctx') and
      recipient ('recipient-ctx') contexts.

      The list 'target-resource' stores policies (bypass,
      discard, protect) related with the target resource that
      this Thing can access'. In case of protection, a node in
      the list has a reference to a node in the list 'context'.

      The list 'local-resource' stores policies related with the
      local resources provided by this Thing.";
    reference ".";
  }

  typedef policy-t {
       type enumeration {
         enum protect {
           description
             "PROTECT the traffic with OSCORE.";
         }
         enum bypass {
           description
             "The CoAP resource does not require
             OSCORE protection";
         }
         enum discard {
           description
             "The CoAP message to a resource is
              discarded.";
         }
       }
       description
         "The policy applicable to access a CoAP resource. There
         are three possible values: BYPASS (the CoAP message is
         unprotected), PROTECT (the CoAP message MUST be
         protected with OSCORE), and DISCARD (The CoAP message
         is discarded).";
  }

  container oscore {

    description
      "Container for configuration of the OSCORE
      case. The container contains a list of OSCORE contexts.
      Each node of the list contains three possible contexts.
      Common Context, Sender  Context and Recipient Context. The
      Controller configures at least the Common Context and
      configure a Sender Context or a Recipient Context or
      both.";

    list context {

      key "id-entry";
      ordered-by user;

      leaf id-entry {
        type binary;
        description
          "Unique name to identify this entry.";
      }

      container common-ctx {
        description
          "This container carries the
          configuration of an OSCORE Common Context.";

        leaf id {
          type binary;
          default 0x00;
          description
            "Optional variable-length byte string providing
            additional information to identify the Common
            Context and to derive AEAD keys and Common IV. The
            use of ID Context is described in Section 5.1 in RFC
            8613";
        }

        leaf aead-alg {
          type uint32;
          default "10";
          description
            "The COSE AEAD algorithm to use for encryption.";
        }

        leaf hkdf-alg {
          type uint32;
          default "1";
          description
            "An HMAC-based key derivation function (HKDF,
            [RFC5869]) used to derive the Sender Key, Recipient
            Key, and Common IV.";
        }

        leaf master-key {
          nacm:default-deny-all;
          type binary;
          description
            "Variable length, random byte string (see
            Section 12.3) in RFC 8613 used to derive AEAD keys
            and Common IV.";
        }

        leaf master-salt {
          nacm:default-deny-all;
          type binary;
          description
            "Optional variable-length byte string
            containing the salt used to derive AEAD
            keys and Common IV.";
        }

      } /*container common-ctx*/

      container sender-ctx {

        description
          "This container carries the
          configuration of an OSCORE Sender Context.";

          leaf id {
            type binary;
            default 0x00;
            description
              "Byte string used to identify the Sender Context,
              to derive AEAD keys and Common IV, and to
              contribute to the uniqueness of AEAD nonces.
              Maximum length is determined by the AEAD
              Algorithm.";
          }

      } /*container sender-ctx*/

      container recipient-ctx {

        description
          "This container carries the
          configuration of an OSCORE Recipient Context.";

          leaf id {
            type binary;
            default 0x01;
            description
              "Byte string used to identify the Recipient
              Context, to derive AEAD keys and Common IV, and to
              contribute to the uniqueness of AEAD nonces.
              Maximum length is determined by the
              AEAD Algorithm.";
          }

          leaf replay-window {
            type uint64;
            default "32";
            description
              "To set the anti-replay window size.
               The default value is set to 32,
               following the recommendation in RFC 8613.";
            reference
              "RFC 8613: Object Security for Constrained
              RESTful Environments (OSCORE),
              Section 3.2.2.";
          }

      } /*container recipient-ctx*/


      container renew-ctx {
        description
          "This container includes information to update the
          OSCORE contexts.";

        choice method {
          default sdn-based;
          case multiple-times {

            container ctx-derivation {
              leaf r1-length {
                type uint64;
                default 8;
                description
                  "R1 length.";
              }
              leaf r2-length {
                type uint64;
                default 8;
                description
                  "R2 length.";
              }
              leaf r3-length {
                type uint64;
                default 8;
                description
                  "R3 length.";
              }
              description
                "This container allow configuring the required
                information so that the security context
                derivation in Appendix B.2 is implemented. The
                Controller is in charge of providing the length
                of R1, R2 and R3. If a node is acting as
                initiator in this procedure, R1 and R3 lengths
                are defined. If it is acting as responder R2
                length applies.";
              reference
                "Appendix B.2 Security Context Derived Multiple
                Times - RFC 8613";
            } /*container ctx-derivation*/

            description
              "Appendix B.2. protocol in RFC 8613 is used to
              renew OSCORE context.";
          } /*case multiple-times*/

          case sdn-based {
            leaf sdn-based {
            type empty;
            description
              "The OSCORE context is updated by the Controller.";
            }
            description
              "The Controller manages the OSCORE renewal time
              and update the contexts when it decides so.";
          } /*case sdn-based*/

        description
        "Different methods to update OSCORE context according
        to RFC 8613 and this document.";
       } /*choice method*/
     } /*container renew-ctx*/

      description
        "The OSCORE contexts is represented as a list of OSCORE
        context entries, where each entry contains a OSCORE
        common context, sender context and recipient context
        associated to the OSCORE common context.";

    } /*list contexts*/

    list target-resource  {
      description
        "This list contains the resources that this peer (acting
        as CoAP client) will access and that requires OSCORE
        protection (depending on the policy) in the other peer
        (acting as a CoAP server). They may be discovered by
        some other means by the Thing but installing them allows
        the device to protect immediately the CoAP message. The
        list is ordered by the Controller. A node in the list is
        evaluated before the next node in the list. If there is
        a match the evaluation is stopped and the policy
        applied. That is nodes at the beginning of the list has
        more priority that final nodes.";

      key "target";
      ordered-by user;

      leaf target {
        type inet:uri;
        description
          "URI to the target resource to be protected with this
          OSCORE Sender Context. If the URI is an empty string
          it means ANY";
      }

      leaf policy {
        type policy-t;
        default 'protect';
        description
          "The policy applied to this resource. Default policy
          is protect. If there is no common context to protect
          the CoAP message is discarded. If the list is empty is
          not possible to access to any resource.";
      }

      leaf id-entry-ref {
        when "../policy = 'protect'";
        type binary;
        description
          "Byte string used to identify the context in the list
          'context' that will be used for this target source.";
      }
    } /*list target-resources*/

    list local-resource {

      description
        "This list contains the resources that may require
        OSCORE protection (depending of the policy) in this peer
        (acting as a CoAP server).";

      key "local";
      ordered-by user;

      leaf local {
        type inet:uri;
        description
          "URI of the local resources to be protected with this
          OSCORE Recipient Context.";
      }

      leaf policy {
        type policy-t;
        default 'protect';
        description
          "The policy applied to this resource. Default policy
          is protect. If there is no common context to protect
          the CoAP message is discarded.";
      }

      leaf id-entry-ref {
        when "../policy = 'protect'";
        type binary;
        description
          "Byte string used to identify the context in the list
          'context' that  will be used for this local source.";
      }
    } /*list local-resources*/

  } /*container oscore*/

} /*module ietf-core-oscore */

Appendix D. OSCORE case example usage

This example shows an XML representation of the configuration sent by the SDN Controller to establish an OSCORE context to Thing 't1' using "signature-key" authentication (RSA) when accessing the resource "coap://2001:db8:cafe:123::200/res1". (Some values are simplified for brevity with "base64encodedvalue==").

SDN Controller Southbound Interface t1 OSCORE t2/res1 :100 :200 (2001:db8:cafe:123:/64)
<oscore xmlns="urn:ietf:params:xml:ns:yang:ietf-core-oscore" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <context> <name>ctx-t1_t2</name> <common-ctx> <id>Mzc6Y2I6ZjM6MjE6MDA6MTc6YTI6ZDM=</id> <aead-alg>10</aead-alg> <hkdf-alg>1</hkdf-alg> <master-key>base64encodedvalue==</master-key> <master-salt>base64encodedvalue==</master-salt> </common-ctx> <sender-ctx> <id>MEY=</id><!-- 0F </sender-ctx> <recipient-ctx> <id>MDE=</id> </recipient-ctx> </context> <target-resource> <target>coap://2001:db8:cafe:123::200/res1</target> <policy>protect</policy> <name-ref>ctx-t1_t2</name-ref> </target-resource> </oscore>

Acknowledgments

Authors want to thank

Authors' Addresses

Rafa Marin-Lopez
University of Murcia
Murcia 30100
Spain
Gabriel Lopez-Millan
University of Murcia
Murcia 30100
Spain
Laurent Toutain
Institut Mines Telecom Atlantique
2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex
France
Alex Fernandez
Institut Mines Telecom Atlantique
2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex
France