Sandelman Software Works

mcr+ietf@sandelman.ca

vanderstok consultancy

consultancy@vanderstok.org

Cisco Systems

pkampana@cisco.com

IoTconsultancy.nl

esko.dijk@iotconsultancy.nl

Internet anima Working Group Internet-Draft This document defines a protocol to securely assign a Pledge to an owner and to enroll it into the owner’s network. The protocol uses an artifact that is signed by the Pledge’s manufacturer. This artifact is known as a “voucher”. This document builds upon the work in and [BRSKI], but defines an encoding of the voucher in CBOR rather than JSON, and enables the Pledge to perform its transactions using CoAP rather than HTTPS. The use of Raw Public Keys instead of X.509 certificates for security operations is also explained.

Secure enrollment of new nodes into constrained networks with constrained nodes presents unique challenges. There are network bandwidth and code size issues to contend with. A solution for autonomous enrollment such as may be too large in terms of code size or bandwidth required. Therefore, this document defines a constrained version of the voucher artifact , along with a constrained version of BRSKI that makes use of the constrained CoAP-based version of EST, EST-coaps rather than EST over HTTPS . While the voucher is by default serialized to JSON with a signature in CMS, this document defines a new voucher serialization to CBOR () with a signature in COSE . This COSE-signed CBOR-encoded voucher can be transported using secured CoAP or HTTP. The CoAP connection (between Pledge and Registrar) is to be protected by either OSCORE+EDHOC, or DTLS (CoAPS). The HTTP connection (between Registrar and MASA) is to be protected using TLS (HTTPS). This document has a similar structure to but adds sections concerning: Voucher-request artifact specification based on Section 3 of , Voucher(-request) transport over CoAP based on Section 3 of and on . The CBOR definitions for the constrained voucher format are defined using the mechanism described in using the SID mechanism explained in . As the tooling to convert YANG documents into a list of SID keys is still in its infancy, the table of SID values presented here should be considered normative rather than the output of the pyang tool. There is additional work when the voucher is integrated into the key-exchange, described in . This work is not in scope for this document.

The following terms are defined in , and are used identically as in that document: artifact, domain, imprint, Join Registrar/Coordinator (JRC), Manufacturer Authorized Signing Authority (MASA), Pledge, Registrar, Trust of First Use (TOFU), and Voucher. The following terms from are used identically as in that document: Domain CA, enrollment, IDevID, Join Proxy, LDevID, manufacturer, nonced, nonceless, PKIX.

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 when, and only when, they appear in all capitals, as shown here.

provides for vouchers that assert proximity, that authenticate the Registrar and that can offer varying levels of anti-replay protection. This document does not make any extensions to the semantic meanings of vouchers, only the encoding has been changed to optimize for constrained devices and networks. Time-based vouchers are supported in this definition, but given that constrained devices are extremely unlikely to have accurate time, their use is very unlikely. Most Pledges using these constrained vouchers will be online during enrollment and will use live nonces to provide anti-replay protection. defined only the voucher artifact, and not the Voucher Request artifact, which was defined in . This document defines both a constrained voucher and a constrained voucher-request. They are presented in the order “voucher-request”, followed by a “voucher” response as this is the order that they occur in the protocol. The constrained voucher request MUST be signed by the Pledge. It can sign using its IDevID X.509 certificate, or if an IDevID is not available its manufacturer-installed raw public key (RPK). The constrained voucher MUST be signed by the MASA. For the constrained voucher request this document defines two distinct methods for the Pledge to identify the Registrar: using either the Registrar’s X.509 certificate, or using a raw public key (RPK) of the Registrar. For the constrained voucher also these two methods are supported to indicate (pin) a trusted domain identity: using either a pinned domain X.509 certificate, or a pinned raw public key (RPK). When the Pledge is known by MASA to support RPK but not X.509 certificates, the voucher produced by the MASA pins the raw public key of the Registrar in the “pinned-domain-subject-public-key-info” field of a voucher. This is described in more detail in the YANG definition for the constrained voucher and in section . When the Pledge is known by MASA to support PKIX format certificates, the “pinned-domain-cert” field present in a voucher typically pins a domain certificate. That can be either the End-Entity certificate of the Registrar, or the certificate of a domain CA of the Registrar’s domain. However, if the Pledge is known to also support RPK pinning and the MASA intends to pin the Registrar’s identity (not a CA), then MASA MAY pin the RPK of the Registrar instead of the Registrar’s End-Entity certificate in order to save space in the voucher.

This section describes the BRSKI extensions to EST-coaps to transport the voucher between Registrar, join proxy and Pledge over CoAP. The extensions are targeted to low-resource networks with small packets. Saving header space is important and the EST-coaps URI is shorter than the EST URI. The presence and location of (path to) the management data are discovered by sending a GET request to “/.well-known/core” including a resource type (RT) parameter with the value “ace.est” . Upon success, the return payload will contain the root resource of the EST resources. It is up to the implementation to choose its root resource; throughout this document the example root resource /est is used. The EST-coaps server URIs differ from the EST URI by replacing the scheme https by coaps and by specifying shorter resource path names:

Figure 5 in section 3.2.2 of enumerates the operations and corresponding paths which are supported by EST. provides the mapping from the BRSKI extension URI path to the EST-coaps URI path. BRSKI EST-coaps /requestvoucher /rv /voucher_status /vs /enrollstatus /es /requestvoucher, /voucher_status and /enrollstatus occur between the Pledge and Registrar (the BRSKI-EST protocol) and also between Registrar and MASA, but, as described in , this document addresses only the BRSKI-EST portion of the protocol. When discovering the root path for the EST resources, the server MAY return the full resource paths and the used content types. This is useful when multiple content types are specified for EST-coaps server. For example, the following more complete response is possible.

The constrained BRSKI-EST protocol described in this section is between the Pledge and the Registrar only. (probably via a join proxy, such as described in ) It extends both the BRSKI and EST-coaps protocols.

The constrained BRSKI-EST protocol described in this section is between the Pledge and the Registrar only. (probably via a join proxy, such as described in ) It extends both the BRSKI and EST-coaps protocols.

TBD: content overlaps with , to be fixed - issue #79 The Pledge MAY perform a discovery operation on the “/.well-known/core?rt=brski*” resource of the Registrar if it wishes to discover possibly shorter URLs for the functions, or if it has the possibility to use a variety of onboarding protocols or certificate enrollment protocols and it wants to discover which of these protocols are available. For example, if the Registrar supports a short BRSKI URL (/b) and supports the voucher format “application/voucher-cose+cbor” (TBD3), and status reporting in both CBOR and JSON formats:

;rt=brski, ;rt=brski.rv;ct=TBD3, ;rt=brski.vs;ct="50 60", ;rt=brski.es;ct="50 60" ]]>

The Registrar is under no obligation to provide shorter URLs, and MAY respond to this query with only the “/.well-known/brski” end points defined in section 5. Registrars that have implemented shorter URLs MUST also respond in equivalent ways to the “/.well-known/brski” URLs, and MUST NOT distinguish between them. In particular, a Pledge MAY use the longer and shorter URLs in combination. The return of multiple content-types in the “ct” attribute allows the Pledge to choose the most appropriate one. Note that Content-Format TBD3 is defined in this document. The Content-Format (“application/json”) 50 MAY be supported and 60 MUST be supported by the Registrar for the /vs and /es resources. Content-Format TBD3 MUST be supported by the Registrar for the /rv resource. If the “ct” attribute is not indicated for this resource, this implies that at least TBD3 is supported. The Pledge and MASA need to support one or more formats (at least TBD3) for the voucher and for the voucher request. The MASA needs to support all formats that the Pledge, produced by that manufacturer, supports.

A Pledge that only supports the EST-coaps enrollment method SHOULD NOT use discovery for BRSKI resources, since it is more efficient to just try the supported enrollment method via the well-known BRSKI/EST-coaps resources, and it avoids the Pledge having to do complex CoRE Link Format parsing. A Registrar SHOULD host any discoverable BRSKI resources on the same (UDP) server port that the Pledge’s DTLS connection is using. This avoids the Pledge having to reconnect using DTLS, in order to access these resources.

A Pledge that only supports the EST-coaps enrollment method SHOULD NOT use discovery for EST-coaps resources, for similar reasons as stated in the previous section. A Registrar SHOULD host any discoverable EST-coaps resources on the same (UDP) server port that the Pledge’s DTLS connection is using. This avoids the Pledge having to reconnect using DTLS, in order to access these resources.

A constrained Pledge SHOULD NOT perform the optional “CSR attributes request” (/att) to minimize network traffic and reduce code size (i.e. by not implementing the complex CSR attributes parsing code). When creating the CSR, the Pledge selects itself which attributes to include. One or more Subject Distinguished Name fields MUST be included. If the Pledge has no specific information on what attributes/fields are desired in the CSR, it MUST use the Subject Distinguished Name fields from its IDevID unmodified. The Pledge may receive such information via the voucher (encoded in a vendor-specific way) or some other, out-of-band means. A constrained Pledge MAY use the following optimized EST-coaps procedure to minimize both network traffic and code size: if the BRSKI-received voucher, validating the current EST server, contains a pinned domain CA certificate, the Pledge provisionally considers this single certificate as the sole EST trust anchor, in other words, the single result of “CA certificates request” (/crts) to the EST server. Using this trust anchor it proceeds with EST simple enrollment (/sen) to obtain its provisionally trusted LDevID. Then, the Pledge attempts to validate that the trust anchor CA is the signer of the LDevID. If this is the case, the Pledge finally accepts the pinned domain CA certificate as the legitimate trust anchor CA for its domain and it also accepts its LDevID. If this is not the case, the Pledge MUST perform an actual “CA certificates request” (/crts) to the EST server to obtain the EST CA trust anchors since these obviously differ from the (temporary) pinned domain CA. When doing this request, the Pledge MAY use a CoAP Accept Option with value TBD287 (“application/pkix-cert”) to limit the number of returned EST CA trust anchors to only one. Such limiting to only one has the advantages that storage requirements for CA certificates are reduced, network traffic can be reduced, and code size can be reduced (by not having to parse the alternative format 281 “application/pkcs7-mime;smime-type=certs-only” and not having to support CoAP block-wise transfer). If the Pledge cannot obtain the single CA certificate or the finally validated CA certificate cannot be chained to the LDevID, then the Pledge MUST abort the enrollment process and report the error using the enrollment status telemetry (/es). The Content-Format (“application/json”) 50 MAY be supported and 60 MUST be supported by the Registrar for the /vs and /es resources. Content-Format TBD3 MUST be supported by the Registrar for the /rv resource. If the “ct” attribute is not indicated for this resource, this implies that at least TBD3 is supported. When a Registrar receives a “CA certificates request” (/crts) request with a CoAP Accept Option with value TBD287 it SHOULD return only the single CA certificate that is the envisioned or actual authority for the current, authenticated Pledge making the request. The only exception case is when the Registrar is configured to not support a request for a single CA certificate for operational or security reasons, e.g. because every device enrolled into the domain needs to use at least multiple CAs. In such exception case the Registrar returns the CoAP response 4.06 Not Acceptable to indicate that only the default Content-Format of 281 “application/pkcs7-mime;smime-type=certs-only” is available.

When a Registrar receives a “CA certificates request” (/crts) request with a CoAP Accept Option with value TBD287 it SHOULD return only the single CA certificate that is the envisioned or actual authority for the current, authenticated Pledge making the request. The only exception case is when the Registrar is configured to not support a request for a single CA certificate for operational or security reasons, e.g. because every device enrolled into the domain needs to use at least multiple CAs. In such exception case the Registrar returns the CoAP response 4.06 Not Acceptable to indicate that only the default Content-Format of 281 “application/pkcs7-mime;smime-type=certs-only” is available.

section 5.4 describes a connection between the Registrar and the MASA as being a normal TLS connection using HTTPS. This document does not change that. The use of CoAP for the BRSKI-MASA connection is NOT supported. Some consideration was made to specify CoAP support for consistency but: the Registrar is not expected to be so constrained that it cannot support HTTPS client connections. the technology and experience to build Internet-scale HTTPS responders (which the MASA is) is common, while the experience doing the same for CoAP is much less common. in many Enterprise networks, outgoing UDP connections are often treated as suspicious, and there seems to be no advantage to using CoAP in that environment. a Registrar is likely to provide onboarding services to both constrained and non-constrained devices. Such a Registrar would need to speak HTTPS anyway. similarly, a manufacturer is likely to offer both constrained and non-constrained devices, so there may in practice be no situation in which the MASA could be CoAP-only. Additionally, as the MASA is intended to be a function that can easily be oursourced to a third-party service provider, reducing the complexity would also seem to reduce the cost of that function.

The voucher is a statement from the MASA to the Pledge indicating who the Pledge’s owner is. This section deals with the question of how that owner’s identity is determined and how it is encoded within the voucher.

Section 5.5 of describes BRSKI policies for selection of the owner identity. It indicates some of the flexibility that is possible for the Registrar. The recommendation made there is for the Registrar to include only certificates in the (CMS) signing structure which participate in the certificate chain that is to be pinned. The MASA is expected to evaluate the certificates included by the Registrar in its voucher request, forming them into a chain with the Registrar’s (signing) identity on one end. Then, it pins a certificate selected from the chain. For instance, for a domain with a two-level certification authority, where the voucher-request has been signed by “Registrar” its signing structure includes two additional CA certificates:

When the Registrar is using a COSE-signed constrained format voucher request towards MASA, instead of a regular CMS-signed voucher request, the COSE_Sign1 object contains a protected and an unprotected header, and according to , would carry all the certificates of the chain in an “x5bag” attribute placed in the unprotected header.

The MASA, having assembled and verified the chain in the signing structure, will now need to select a certificate to pin in the voucher in case there are multiple available. (For the case that only the Registrar’s End-Entity certificate is included, only this certificate can be selected and this section does not apply.) The BRSKI policy for pinning by the MASA as described in Section 5.5.2 of leaves much flexibility to the manufacturer. The present document adds the following rules to the MASA pinning policy, in order to reduce on average the duration of BRSKI/EST on constrained, low-bandwidth networks: for a voucher containing a nonce, it SHOULD select the most specific (lowest-level) CA certificate in the chain. for a nonceless voucher, it SHOULD select the least-specific (highest-level) CA certificate in the chain that is allowed under the MASA’s policy for this specific customer (domain). The rationale for 1. is that in case of a voucher with nonce, the voucher is valid only in scope of the present DTLS connection between Pledge and Registrar anyway, so it would have no benefit to pin a higher-level CA. By pinning the most specific CA the constrained Pledge can validate its DTLS connection using less crypto operations. The rationale for pinning a CA instead of the Registrar’s End-Entity certificate directly is the following benefit on constrained networks: the pinned certificate in the voucher can in common cases be re-used as a Domain CA trust anchor during the EST enrollment and during the operational phase that follows after EST enrollment, as explained elsewhere in this document. Doing so avoids an additional transmission of this trust anchor over the network during the EST enrollment, saving potentially 100s of bytes and a CoAP transaction. The rationale for 2. follows from the flexible BRSKI trust model for, and purpose of, nonceless vouchers (Sections 5.5.* and 7.4.1 of ). Using the previous example of a domain with a two-level certification authority, the most specific CA (“Sub-CA”) is the identity that is pinned by MASA in a nonced voucher. A Registrar that wished to have only the Registrar’s End-Entity certificate pinned would omit the “priv-CA” and “Sub-CA” certificates from the voucher-request. In case of a nonceless voucher, the MASA would depending on trust level pin only “Registrar” certificate (low trust in customer), or the “Sub-CA” certificate (in case of medium trust, implying that any Registrar of that sub-domain is acceptable), or even the “priv-CA” certificate (in case of high trust in the customer, and possibly a pre-agreed need of the customer to obtain flexible long-lived vouchers).

Specifically for constrained use cases, the pinning of the raw public key (RPK) of the Registrar is also supported in the constrained voucher, instead of an X.509 certificate. If an RPK is pinned it MUST be the RPK of the Registrar.

When the Pledge is known by MASA to support RPK but not X.509 certificates, the voucher produced by the MASA pins the RPK of the Registrar in the “pinned-domain-subject-public-key-info” field of a voucher. This is described in more detail in the YANG definition for the constrained voucher. A Pledge that does not support X.509 certificates cannot use EST to enroll; it has to use another method for certificate-less enrollment and the Registrar has to support this method also. It is possible that the Pledge will not enroll, but instead only a network join operation will occur, such as described in . How the Pledge discovers this method and details of the enrollment method are out of scope of this document. When the Pledge is known by MASA to support PKIX format certificates, the “pinned-domain-cert” field present in a voucher typically pins a domain certificate. That can be either the End-Entity certificate of the Registrar, or the certificate of a domain CA of the Registrar’s domain. However, if the Pledge is known to also support RPK pinning and the MASA intends to pin the Registrar’s identity (not a CA), then MASA SHOULD pin the RPK (RPK3 in figure ) of the Registrar instead of the Registrar’s End-Entity certificate in order to save space in the voucher. To Be Completed further (TBD): Note, the above paragraphs are duplicated from the section so we may have to resolve this duplication.

This section describes the abstract (tree) definition as explained in first. This provides a high-level view of the contents of each artifact. Then the assigned SID values are presented. These have been assigned using the rules in , with an allocation that was made via the http://comi.space service.

The following diagram is largely a duplicate of the contents of , with the addition of proximity-registrar-subject-public-key-info, proximity-registrar-cert, and prior-signed-voucher-request. prior-signed-voucher-request is only used between the Registrar and the MASA. proximity-registrar-subject-public-key-info replaces proximity-registrar-cert for the extremely constrained cases.

In the constrained-voucher-request YANG module, the voucher is “augmented” within the “used” grouping statement such that one continuous set of SID values is generated for the constrained-voucher-request module name, all voucher attributes, and the constrained-voucher-request attribute. Two attributes of the voucher are “refined” to be optional.

file "ietf-constrained-voucher-request@2019-09-01.yang" module ietf-constrained-voucher-request { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request"; prefix "constrained"; import ietf-restconf { prefix rc; description "This import statement is only present to access the yang-data extension defined in RFC 8040."; reference "RFC 8040: RESTCONF Protocol"; } import ietf-voucher { prefix "v"; } organization "IETF ANIMA Working Group"; contact "WG Web: WG List: Author: Michael Richardson Author: Peter van der Stok Author: Panos Kampanakis "; description "This module defines the format for a voucher request, which is produced by a pledge to request a voucher. The voucher-request is sent to the potential owner's Registrar, which in turn sends the voucher request to the manufacturer or delegate (MASA). A voucher is then returned to the pledge, binding the pledge to the owner. This is a constrained version of the voucher-request present in draft-ietf-anima-bootstrap-keyinfra.txt. This version provides a very restricted subset appropriate for very constrained devices. In particular, it assumes that nonce-ful operation is always required, that expiration dates are rather weak, as no clocks can be assumed, and that the Registrar is identified by a pinned Raw Public Key. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described in RFC 2119."; revision "2019-09-01" { description "Initial version"; reference "RFC XXXX: Voucher Profile for Constrained Devices"; } rc:yang-data voucher-request-constrained-artifact { // YANG data template for a voucher. uses voucher-request-constrained-grouping; } // Grouping defined for future usage grouping voucher-request-constrained-grouping { description "Grouping to allow reuse/extensions in future work."; uses v:voucher-artifact-grouping { refine voucher/created-on { mandatory false; } refine voucher/pinned-domain-cert { mandatory false; } augment "voucher" { description "Base the constrained voucher-request upon the regular one"; leaf proximity-registrar-subject-public-key-info { type binary; description "The proximity-registrar-subject-public-key-info replaces the proximit-registrar-cert in constrained uses of the voucher-request. The proximity-registrar-subject-public-key-info is the Raw Public Key of the Registrar. This field is encoded as specified in RFC7250, section 3. The ECDSA algorithm MUST be supported. The EdDSA algorithm as specified in draft-ietf-tls-rfc4492bis-17 SHOULD be supported. Support for the DSA algorithm is not recommended. Support for the RSA algorithm is MAY, but due to size is discouraged."; } leaf proximity-registrar-sha256-of-subject-public-key-info { type binary; description "The proximity-registrar-sha256-of-subject-public-key-info is an alternative to proximity-registrar-subject-public-key-info. and pinned-domain-cert. In many cases the public key of the domain has already been transmitted during the key agreement protocol, and it is wasteful to transmit the public key another two times. The use of a hash of public key info, at 32-bytes for sha256 is a significant savings compared to an RSA public key, but is only a minor savings compared to a 256-bit ECDSA public-key. Algorithm agility is provided by extensions to this specifications which define new leaf for other hash types."; } leaf proximity-registrar-cert { type binary; description "An X.509 v3 certificate structure as specified by RFC 5280, Section 4 encoded using the ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690. The first certificate in the Registrar TLS server certificate_list sequence (see [RFC5246]) presented by the Registrar to the Pledge. This MUST be populated in a Pledge's voucher request if the proximity assertion is populated."; } leaf prior-signed-voucher-request { type binary; description "If it is necessary to change a voucher, or re-sign and forward a voucher that was previously provided along a protocol path, then the previously signed voucher SHOULD be included in this field. For example, a pledge might sign a proximity voucher, which an intermediate registrar then re-signs to make its own proximity assertion. This is a simple mechanism for a chain of trusted parties to change a voucher, while maintaining the prior signature information. The pledge MUST ignore all prior voucher information when accepting a voucher for imprinting. Other parties MAY examine the prior signed voucher information for the purposes of policy decisions. For example this information could be useful to a MASA to determine that both pledge and registrar agree on proximity assertions. The MASA SHOULD remove all prior-signed-voucher-request information when signing a voucher for imprinting so as to minimize the final voucher size."; } } } } } ]]>

Below is a CBOR serialization of an example constrained voucher request from a Pledge to a Registrar, shown in CBOR diagnostic notation. The enum value of the assertion field is calculated to be 2 by following the algorithm described in section 9.6.4.2 of . Four dots (“….”) in a CBOR byte string denotes a sequence of bytes that are not shown for brevity.

]]>

The voucher’s primary purpose is to securely assign a Pledge to an owner. The voucher informs the Pledge which entity it should consider to be its owner.

The following diagram is largely a duplicate of the contents of , with only the addition of pinned-domain-subject-public-key-info.

]]>

]]>

In the constrained-voucher YANG module, the voucher is “augmented” within the “used” grouping statement such that one continuous set of SID values is generated for the constrained-voucher module name, all voucher attributes, and the constrained-voucher attribute. Two attributes of the voucher are “refined” to be optional.

file "ietf-constrained-voucher@2019-09-01.yang" module ietf-constrained-voucher { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; prefix "constrained"; import ietf-restconf { prefix rc; description "This import statement is only present to access the yang-data extension defined in RFC 8040."; reference "RFC 8040: RESTCONF Protocol"; } import ietf-voucher { prefix "v"; } organization "IETF ANIMA Working Group"; contact "WG Web: WG List: Author: Michael Richardson Author: Peter van der Stok Author: Panos Kampanakis "; description "This module defines the format for a voucher, which is produced by a pledge's manufacturer or delegate (MASA) to securely assign one or more pledges to an 'owner', so that the pledges may establis a secure connection to the owner's network infrastructure. This version provides a very restricted subset appropriate for very constrained devices. In particular, it assumes that nonce-ful operation is always required, that expiration dates are rather weak, as no clocks can be assumed, and that the Registrar is identified by a pinned Raw Public Key. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described in RFC 2119."; revision "2019-09-01" { description "Initial version"; reference "RFC XXXX: Voucher Profile for Constrained Devices"; } rc:yang-data voucher-constrained-artifact { // YANG data template for a voucher. uses voucher-constrained-grouping; } // Grouping defined for future usage grouping voucher-constrained-grouping { description "Grouping to allow reuse/extensions in future work."; uses v:voucher-artifact-grouping { refine voucher/created-on { mandatory false; } refine voucher/pinned-domain-cert { mandatory false; } augment "voucher" { description "Base the constrained voucher upon the regular one"; leaf pinned-domain-subject-public-key-info { type binary; description "The pinned-domain-subject-public-key-info replaces the pinned-domain-cert in constrained uses of the voucher. The pinned-domain-subject-public-key-info is the Raw Public Key of the Registrar. This field is encoded as specified in RFC7250, section 3. The ECDSA algorithm MUST be supported. The EdDSA algorithm as specified in draft-ietf-tls-rfc4492bis-17 SHOULD be supported. Support for the DSA algorithm is not recommended. Support for the RSA algorithm is a MAY."; } leaf pinned-sha256-of-subject-public-key-info { type binary; description "The pinned-hash-subject-public-key-info is a second alternative to pinned-domain-cert. In many cases the public key of the domain has already been transmitted during the key agreement process, and it is wasteful to transmit the public key another two times. The use of a hash of public key info, at 32-bytes for sha256 is a significant savings compared to an RSA public key, but is only a minor savings compared to a 256-bit ECDSA public-key. Algorithm agility is provided by extensions to this specifications which define new leaf for other hash types"; } } } } } ]]>

Below the CBOR serialization of an example constrained voucher is shown in CBOR diagnostic notation. The enum value of the assertion field is calculated to be zero by following the algorithm described in section 9.6.4.2 of . Four dots (“….”) in a CBOR byte string denotes a sequence of bytes that are not shown for brevity.

]]>

The COSE-Sign1 structure is discussed in section 4.2 of . The CBOR object that carries the body, the signature, and the information about the body and signature is called the COSE_Sign1 structure. It is used when only one signature is used on the body. Support for ECDSA with sha256 (secp256k1 and prime256v1 curves) is compulsory. The supported COSE-sign1 object stucture is shown in . Support for EdDSA is encouraged. [EDNOTE: Expand and add a reference why. ]

The specifies the integers that replace the strings and the mnemonics in . The value of the “kid” parameter is an example value. Usually a hash of the public key is used to idientify the public key. The public key and its hash are derived from the relevant certificate (Pledge, Registrar or MASA certificate). In a binary cose-sign1 object is shown based on the voucher-request example of .

The design considerations for the CBOR encoding of vouchers is much the same as for . One key difference is that the names of the leaves in the YANG does not have a material effect on the size of the resulting CBOR, as the SID translation process assigns integers to the names. Any POST request to the Registrar with resource /est/vs or /est/es returns a 2.05 response with empty payload. The client should be aware that the server may use a piggybacked CoAP response (ACK, 2.05) but may also respond with a separate CoAP response, i.e. first an (ACK, 0.0) that is an acknowledgement of the request reception followed by a (CON, 2.05) response in a separate CoAP message.

TBD.

TBD.

TBD.

Additions to the sub-registry “CoAP Resource Type”, within the “CoRE parameters” registry are specified below. These can be registered either in the Expert Review range (0-255) or IETF Review range (256-9999).

This document registers two URIs in the IETF XML registry . Following the format in , the following registration is requested:

This document registers two YANG modules in the YANG Module Names registry . Following the format defined in , the the following registration is requested:

Warning: These SID values are defined in , not as an Early Allocation.

This section registers the the ‘application/voucher-cose+cbor’ in the “Media Types” registry. These media types are used to indicate that the content is a CBOR voucher either signed with a COSE_Sign1 structure .

Additions to the sub-registry “CoAP Content-Formats”, within the “CoRE Parameters” registry are needed for two media types. These can be registered either in the Expert Review range (0-255) or IETF Review range (256-9999).

We are very grateful to Jim Schaad for explaining COSE and CMS choices. Also thanks to Jim Schaad for correctinging earlier version of the COSE Sign1 objects. Michel Veillette did extensive work on pyang to extend it to support the SID allocation process, and this document was among the first users.

-10 Design considerations extended Examples made consistent -08 Examples for cose_sign1 are completed and improved. -06 New SID values assigned; regenerated examples -04 voucher and request-voucher MUST be signed examples for signed request are added in appendix IANA SID registration is updated SID values in examples are aligned signed cms examples aligned with new SIDs -03

-02

-01

The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. Trilliant Networks Inc. Google Switzerland GmbH Acklio This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, action input, action output, notifications and yang-data extension defined within YANG modules using the Concise Binary Object Representation (CBOR, RFC 8949). Trilliant Networks Inc. Acklio Acklio YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned integers used to identify YANG items. This document defines the semantics, the registration, and assignment processes of YANG SIDs. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher".This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)).This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] August Cellars Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes RFC8152. Cisco Sandelman Software Works Futurewei Technologies Inc. USA Watsen Networks This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. Consultant Cisco Systems Sandelman Software Works RISE SICS Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. August Cellars The CBOR Signing And Encrypted Message (COSE) structure uses references to keys in general. For some algorithms, additional properties are defined which carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. Ericsson AB Ericsson AB INRIA Sandelman Software Works Institute of Embedded Systems, ZHAW This document describes a procedure for augmenting the authenticated Diffie-Hellman key exchange EDHOC with third party assisted authorization targeting constrained IoT deployments (RFC 7228). Note to Readers Source for this draft and an issue tracker can be found at https://github.com/EricssonResearch/ace-ake-authz (https://github.com/EricssonResearch/ace-ake-authz). In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Inria Analog Devices University of California Berkeley Sandelman Software Works This document describes the minimal framework required for a new device, called "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) network. The framework requires that the pledge and the JRC (join registrar/coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. Tail-f Systems LabN Consulting, L.L.C. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. Sandelman Software Works vanderstok consultancy Cisco Systems This document defines a protocol to securely assign a pledge to a domain, represented by a Registrar, using an intermediary node between pledge and Registrar. This intermediary node is known as a "constrained Join Proxy". This document extends the work of [I-D.ietf-anima-bootstrapping-keyinfra] by replacing the Circuit- proxy by a stateless/stateful constrained (CoAP) Join Proxy. It transports join traffic from the pledge to the Registrar without requiring per-client state.

This section extends the examples from Appendix A of . The CoAP headers are only worked out for the enrollstatus example.

A coaps enrollstatus message can be :

The corresponding coap header fields are shown below.

The Uri-Host and Uri-Port Options are omitted because they coincide with the transport protocol destination address and port respectively. A 2.05 Content response with an unsigned voucher status (ct=60) will then be:

With CoAP fields and payload:

The binary payload is:

The binary payload disassembles to the above CBOR diagnostic code.

A coaps voucher_status message can be:

A 2.05 Content response with a non signed CBOR voucher status (ct=60) will then be:

]]>

The payload above is represented in hexadecimal.

]]>

These examples are generated on a pie 4 and a PC running BASH. Keys and Certificates have been generated with openssl with the following shell script:

serial echo 1000 > crlnumber # intermediate level mkdir intermediate cd intermediate mkdir certs crl csr newcerts private chmod 700 private touch index.txt echo 11223344556600 >serial echo 1000 > crlnumber cd ../.. # file structure is cleaned start filling echo "#############################" echo "create registrar keys and certificates " echo "#############################" echo "create root registrar certificate using ecdsa with sha 256 key" $OPENSSL_BIN ecparam -name prime256v1 -genkey \ -noout -out $cadir/private/ca-regis.key $OPENSSL_BIN req -new -x509 \ -config $cnfdir/openssl-regis.cnf \ -key $cadir/private/ca-regis.key \ -out $cadir/certs/ca-regis.crt \ -extensions v3_ca\ -days 365 \ -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=consultancy \ /CN=registrar.stok.nl" # Combine authority certificate and key echo "Combine authority certificate and key" $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ -inkey $cadir/private/ca-regis.key \ -in $cadir/certs/ca-regis.crt -export \ -out $cadir/certs/ca-regis-comb.pfx # converteer authority pkcs12 file to pem echo "converteer authority pkcs12 file to pem" $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ -in $cadir/certs/ca-regis-comb.pfx \ -out $cadir/certs/ca-regis-comb.crt -nodes #show certificate in registrar combined certificate $OPENSSL_BIN x509 -in $cadir/certs/ca-regis-comb.crt -text # # Certificate Authority for MASA # echo "#############################" echo "create MASA keys and certificates " echo "#############################" echo "create root MASA certificate using ecdsa with sha 256 key" $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \ -out $cadir/private/ca-masa.key $OPENSSL_BIN req -new -x509 \ -config $cnfdir/openssl-masa.cnf \ -days 1000 -key $cadir/private/ca-masa.key \ -out $cadir/certs/ca-masa.crt \ -extensions v3_ca\ -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturer\ /CN=masa.stok.nl" # Combine authority certificate and key echo "Combine authority certificate and key for masa" $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ -inkey $cadir/private/ca-masa.key \ -in $cadir/certs/ca-masa.crt -export \ -out $cadir/certs/ca-masa-comb.pfx # converteer authority pkcs12 file to pem for masa echo "converteer authority pkcs12 file to pem for masa" $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ -in $cadir/certs/ca-masa-comb.pfx \ -out $cadir/certs/ca-masa-comb.crt -nodes #show certificate in pledge combined certificate $OPENSSL_BIN x509 -in $cadir/certs/ca-masa-comb.crt -text # # Certificate for Pledge derived from MASA certificate # echo "#############################" echo "create pledge keys and certificates " echo "#############################" # Pledge derived Certificate echo "create pledge derived certificate using ecdsa with sha 256 key" $OPENSSL_BIN ecparam -name prime256v1 -genkey -noout \ -out $dir/private/pledge.key echo "create pledge certificate request" $OPENSSL_BIN req -nodes -new -sha256 \ -key $dir/private/pledge.key -out $dir/csr/pledge.csr \ -subj "/C=NL/ST=NB/L=Helmond/O=vanderstok/OU=manufacturing\ /CN=uuid:$DevID/$serialNumber" # Sign pledge derived Certificate echo "sign pledge derived certificate " $OPENSSL_BIN ca -config $cnfdir/openssl-pledge.cnf \ -extensions 8021ar_idevid\ -days 365 -in $dir/csr/pledge.csr \ -out $dir/certs/pledge.crt # Add pledge key and pledge certificate to pkcs12 file echo "Add derived pledge key and derived pledge \ certificate to pkcs12 file" $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ -inkey $dir/private/pledge.key \ -in $dir/certs/pledge.crt -export \ -out $dir/certs/pledge-comb.pfx # converteer pledge pkcs12 file to pem echo "converteer pledge pkcs12 file to pem" $OPENSSL_BIN pkcs12 -passin pass:watnietweet -passout pass:watnietweet\ -in $dir/certs/pledge-comb.pfx \ -out $dir/certs/pledge-comb.crt -nodes #show certificate in pledge-comb.crt $OPENSSL_BIN x509 -in $dir/certs/pledge-comb.crt -text #show private key in pledge-comb.crt $OPENSSL_BIN ecparam -name prime256v1\ -in $dir/certs/pledge-comb.crt -text ]]>

The xxxx-comb certificates have been generated as required by libcoap for the DTLS connection generation.

This first section documents the public and private keys used in the subsequent test vectors below. These keys come from test code and are not used in any production system, and should only be used only to validate implementations.

]]>

]]>

]]>

Below the certificates that accompany the keys. The certificate description is followed by the hexadecimal DER of the certificate

]]>

This is the hexadecimal representation in (request-)voucher examples referred to as pledge-cert-hex.

]]>

]]>

This the hexadecimal representation, in (request-)voucher examples referred to as regis-cert-hex

]]>

]]>

This is the hexadecimal representation, in (request-)voucher examples referred to as masa-cert-hex.

]]>

In this example the voucher request has been signed by the Pledge, and has been sent to the JRC over CoAPS. The Pledge uses the proximity assertion together with an included proximity-registrar-cert field to inform MASA about its proximity to the specific Registrar.

The payload signed_request_voucher is shown as hexadecimal dump (with lf added):

]]>

The representiation of signed_voucher_request in CBOR diagnostic format is:

]]>

In this example the voucher request has been signed by the JRC using the private key from . Contained within this voucher request is the voucher request from the Pledge to JRC.

The payload signed_masa_voucher_request is shown as hexadecimal dump (with lf added):

]]>

The representiation of signed_masa_voucher_request in CBOR diagnostic format is:

]]>

The resulting voucher is created by the MASA and returned via the JRC to the Pledge. It is signed by the MASA’s private key and can be verified by the Pledge using the MASA’s public key contained within the MASA certificate. This is the raw binary signed_voucher, encoded in hexadecimal (with lf added):

]]>

The representiation of signed_voucher in CBOR diagnostic format is:

]]>