Protecting EST Payloads with OSCORE

1.1. Operational Differences with EST-coaps

The protection of EST payloads defined in this document builds on EST-coaps [RFC9148] but transport layer security is replaced, or complemented, by protection of the transfer- and application layer data (i.e., CoAP message fields and payload). This specification deviates from EST-coaps in the following respects:¶

• The DTLS record layer is replaced by, or complemented with, OSCORE.¶

• The DTLS handshake is replaced by, or complemented with, the lightweight authenticated key exchange protocol EDHOC [I-D.ietf-lake-edhoc], and makes use of the following features:¶

  • Authentication based on certificates is complemented with authentication based on raw public keys.¶

  • Authentication based on signature keys is complemented with authentication based on static Diffie-Hellman keys, for certificates/raw public keys.¶

  • Authentication based on certificate by value is complemented with authentication based on certificate/raw public keys by reference.¶

• The EST payloads protected by OSCORE can be proxied between constrained networks supporting CoAP/CoAPs and non-constrained networks supporting HTTP/HTTPs with a CoAP-HTTP proxy protection without any security processing in the proxy (see Section 5). The concept "Registrar" and its required trust relation with the EST server as described in Section 5 of [RFC9148] is therefore not applicable.¶

So, while the same authentication scheme (Diffie-Hellman key exchange authenticated with transported certificates) and the same EST payloads as EST-coaps also apply to EST-oscore, the latter specifies other authentication schemes. The reason for these deviations is that a significant overhead can be removed in terms of message sizes and round trips by using a different handshake, public key type or transported credential, and those are independent of the actual enrollment procedure.¶

3.1. EDHOC

EDHOC supports authentication with certificates/raw public keys (referred to as "credentials"), and the credentials may either be transported in the protocol, or referenced. This is determined by the identifier of the credential of the endpoint, ID_CRED_x for x= Initiator/Responder, which is transported in an EDHOC message. This identifier may be the credential itself (in which case the credential is transported), or a pointer such as a URI to the credential (e.g., x5u, see [RFC9360]) or some other identifier which enables the receiving endpoint to retrieve the credential.¶

3.2. Certificate-based Authentication

EST-oscore, like EST-coaps, supports certificate-based authentication between the EST client and server. The client MUST be configured with an Implicit or Explicit Trust Anchor (TA) [RFC7030] database, enabling the client to authenticate the server. During the initial enrollment the client SHOULD populate its Explicit TA database and use it for subsequent authentications.¶

The EST client certificate SHOULD conform to [RFC7925]. The EST client and/or EST server certificate MAY be a (natively signed) CBOR certificate [I-D.ietf-cose-cbor-encoded-cert].¶

3.3. Channel Binding

The [RFC5272] specification describes proof-of-possession as the ability of a client to prove its possession of a private key which is linked to a certified public key. In case of a signature key, a proof-of-possession is generated by the client when it signs the PKCS#10 Request during the enrollment phase. In case of a static DH key, a proof-of-possession is generated by the client when it generates a MAC and includes it in the PKCS#10 request, as per Section 4.8.¶

Connection-based channel binding refers to the security binding between the PKCS#10 object and the underlying secure transport layer. This is typically achieved by including the challengePassword attribute in the PKCS#10 object that is dependent on the underlying security session. Connection-based proof-of-possession using the challengePassword attribute of the PKCS#10 object is OPTIONAL, see Section 6.¶

3.4. Optimizations

• The third message of the EDHOC protocol, message_3, MAY be combined with an OSCORE request, enabling authenticated Diffie-Hellman key exchange and a protected CoAP request/response (which may contain an enrolment request and response) in two round trips [I-D.ietf-core-oscore-edhoc].¶

• The enrolled certificates MAY be the CBOR-encoded certificates defined in [I-D.ietf-cose-cbor-encoded-cert].¶

• The enrolled client certificate MAY be referenced instead of transported [RFC9360]. The EST-oscore server MAY use information in the credential identifier field of the EDHOC message (ID_CRED_x) to access the EST-oscore client certificate, e.g., in a directory or database provided by the issuer. In this case the certificate may not need to be transported over a constrained link between EST client and server.¶

• Conversely, the response to the PKCS#10 request MAY specify a reference to the enrolled certificate rather than the certificate itself. The EST-oscore server MAY in the enrolment response to the EST-oscore client include a pointer to a directory or database where the certificate can be retrieved.¶

• The PKCS#10 object MAY request a certificate for a static DH key instead of a signature key. This may result in a more compact request because the use of static DH keys may imply a proof-of-posession using a MAC, which is shorter than a signature. Additionally, subsequent EDHOC sessions using static DH keys for authentication have less overhead than key exchange protocols using signature-based authentication credentials.¶

4.1. Discovery and URI

The discovery of EST resources and the definition of the short EST-coaps URI paths specified in Section 4.1 of [RFC9148], as well as the new Resource Type defined in Section 8.2 of [RFC9148] apply to EST-oscore. Support for OSCORE is indicated by the "osc" attribute defined in Section 9 of [RFC8613].¶

Example:¶

     REQ: GET /.well-known/core?rt=ace.est.sen

     RES: 2.05 Content
   </est>; rt="ace.est.sen";osc

The use of the "osc" attribute is REQUIRED. In scenarios where OSCORE and DTLS are combined, the absence of the "osc" attribute might wrongly suggest that the EST server is actually using EST-coaps, because of the scheme "coaps", when it is using EST-oscore.¶

4.2. Mandatory/optional EST Functions

The EST-oscore specification has the same set of required-to-implement functions as EST-coaps. The content of Table 1 is adapted from Section 4.2 in [RFC9148] and uses the updated URI paths (see Section 4.1).¶

4.3. Payload formats

Similar to EST-coaps, EST-oscore allows transport of DER-encoded objects of a given Media-Type. When transporting DER-encoded objects, EST-oscore uses the same CoAP Content-Format identifiers as EST-coaps when transferring EST requests and responses. In addition, EST-oscore allows the transport of CBOR-encoded objects, signaled via their corresponding Media-Type.¶

EST-oscore servers MUST support both the DER-encoded ASN.1 objects and the CBOR-encoded objects. This means supporting formats detailed in Section 4.3.1 and Section 4.3.2. It is up to the client to support only DER-encoded ASN.1, CBOR encoding, or both. As a reminder, Content-Format negotiation happens through CoAP's Accept option present in the requests.¶

4.4. Message Bindings

Note that the EST-oscore message characteristics are identical to those specified in Section 4.4 of [RFC9148]. It is therefore required that¶

• The EST-oscore endpoints support delayed responses¶

• The endpoints supports the following CoAP options: OSCORE, Uri-Host, Uri-Path, Uri-Port, Content-Format, Block1, Block2, and Accept.¶

• The EST URLs based on https:// are translated to coap://, but with mandatory use of the CoAP OSCORE option. In case DTLS is additionally used, the translation target is the scheme "coaps", instead of "coap".¶

4.5. CoAP response codes

See Section 4.5 in [RFC9148].¶

4.6. Message fragmentation

The EDHOC key exchange is optimized for message overhead, in particular the use of static DH keys instead of signature keys for authentication (e.g., method 3 of [I-D.ietf-lake-edhoc]). Together with various measures listed in this document such as CBOR-encoded payloads [RFC8949], CBOR certificates [I-D.ietf-cose-cbor-encoded-cert], certificates by reference (Section 3.4), and trust anchors without signature (Section 4.2.1), a significant reduction of message sizes can be achieved.¶

Nevertheless, depending on the application, the protocol messages may become larger than the available frame size thus resulting in fragmentation and, in resource constrained networks such as IEEE 802.15.4 where throughput is limited, fragment loss can trigger costly retransmissions.¶

It is recommended to prevent IP fragmentation, since it involves an error-prone datagram reassembly. To limit the size of the CoAP payload, this document specifies the requirements on implementing CoAP options Block1 and Block2. EST-oscore servers MUST implement Block1 and Block2. EST-oscore clients MUST implement Block2 and MAY implement Block1.¶

4.7. Delayed Responses

See Section 4.7 in [RFC9148].¶

4.8. Enrollment of Static DH Keys

This section specifies how the EST client enrolls a static DH key. In general, a given key pair should only be used for a single purpose, such as key establishment, digital signature, key transport.¶

The EST client attempting to enroll a DH key for a key usage operation other than digital signature SHOULD use an alternative proof-of-possession algorithm: The EST client SHOULD prepare the PKCS#10 object and compute a MAC, replacing the signature, over the certification request information by following the steps in Section 6 of [RFC6955]. The Key Derivation Function (KDF) and the MAC MUST be set to the HDKF and HMAC algorithms used by OSCORE. The KDF and MAC is thus defined by the hash algorithm used by OSCORE in HKDF and HMAC, which by default is SHA-256. When EDHOC is used, then the hash algorithm is the application hash algorithm of the selected cipher suite.¶

To generate a MAC according to the algorithm outlined in Section 6 of [RFC6955], the client needs to know the public DH key of the proof-of-possession recipient/verifier, i.e. the EST server. In the general case, the EST client MAY obtain the CA certs including the CA's DH certificate using the /crts function using an explicit request/response flow. The obtained certificate indicates the DH group parameters which MUST be respected by the EST client when generating its own DH key pair.¶

As an optimization, when EDHOC precedes the enrollment and combined OSCORE-EDHOC flow is being used in EDHOC message_3 and message_4 per [I-D.ietf-core-oscore-edhoc], the client MUST use the public ephemeral key of the EDHOC Responder, G_Y, as the recipient public key in the algorithm outlined in Section 6 of [RFC6955]. When generating its DH key pair, the client uses the group parameters as indicated by the EDHOC cipher suite in use in the EDHOC session. Because the combined delivery is used per [I-D.ietf-core-oscore-edhoc], the client has already in EDHOC message_2 obtained the ephemeral key G_Y of the server.¶

In some cases, it may be beneficial to exceptionally use the static DH private key associated to the public key used in enrollment for a one-time signing operation of the CSR. While a key pair should only be used for a single purpose (e.g. key establishment or signing), this exceptional use for one-time signing of the CSR is allowed, as discussed in Section 5.6.3.2 of [SP-800-56A] and Section 5.2 of [SP-800-57].¶

6.1. Server-generated Private Keys

This document enables the EST client to request generation of private keys and the enrollment of the corresponding public key through /skg and /skc functions. As discussed in Section 9 of [RFC9148], the transport of private keys generated at EST-server is inherently risky. The use of server-generated private keys may lead to the increased probability of digital identity theft. Therefore, implementations SHOULD NOT use server-generated private key EST functions.¶

A cryptographically secure pseudo-random number generator is required to be available to generate good quality private keys on EST-clients. A cryptographically secure pseudo-random number generator is also a dependency of many security protocols. This includes the EDHOC protocol, which EST-oscore uses for the mutual authentication of EST-client and EST-server. If EDHOC is used and a secure pseudo-random number generator is available, the EST-client MUST NOT use server-generated private key EST functions. However, EST-oscore also allows pre-shared OSCORE contexts to be used for authentication, meaning that EDHOC may not necessarily be required in the protocol stack of an EST-client. If EDHOC is not used for authentication, and the EST-client device does not have a cryptographically secure pseudo-random number generator, then the EST-client MAY use the server-generated private key functions.¶

Although hardware random number generators are becoming dominantly present in modern IoT devices, it has been shown that many available hardware modules contain vulnerabilities and do not produce cryptographically secure random numbers. It is therefore important to use multiple randomness sources to seed the cryptographically secure pseudo-random number generator.¶

6.2. Considerations on Channel Binding

Section 3 of [RFC9148] specifies that the use of connection-based channel binding is optional, and achieves it by including the tls-unique value in the CSR. This specification when used with EDHOC for the enrollment of static DH keys achieves connection-based channel binding by using the EDHOC ephemeral key of the responder as the public key in the proof-of-possession algorithm which generates a PKCS#10 MAC. Therefore, connection-based channel binding is in this case achieved without any additional overhead. In other cases, including pre-shared OSCORE contexts, this specification makes explicit channel binding based on the challengePassword attribute in PKCS#10 requests OPTIONAL. The challengePassword attribute could be used for freshness in the case of pre-shared OSCORE contexts and a re-enrollment request. How challengePassword is generated is outside of the scope of this specification and can be specified by an application profile.¶

7.1. EDHOC Exporter Label Registry

IANA is requested to register the following entry in the "EDHOC Exporter Label" registry under the group name "Ephemeral Diffie-Hellman Over COSE (EDHOC).¶