Internet-Draft EST-coaps-no-cert October 2026
Mittal & Hett Expires 12 April 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-mittal-est-coap-no-cert-00
Published:
Intended Status:
Informational
Expires:
Authors:
N. Mittal
Landis+Gyr
C. Hett
Landis+Gyr

EST-coaps Enrollment Using Device-Unique Symmetric Keys for Field Devices without Initial Certificates

Abstract

This document specifies a profile for Enrollment over Secure Transport using secure CoAP, where the EST-coaps client is a field device that does not possess an initial device certificate, manufacturer certificate, or other certificates usable for DTLS client authentication. Instead, the device is authenticated during the DTLS handshake using a device-unique symmetric key or a pre-shared key derived from that device-unique key.

This profile is intended for already registered and operational devices that do not possess a certificate suitable for EST-coaps client authentication but do possess a device-unique symmetric key that can be used for initial authentication during certificate enrollment. The mechanism preserves EST certificate enrollment semantics while replacing the initial certificate-based DTLS client authentication requirement with PSK-based DTLS authentication. [RFC9148] defines EST over secure CoAP and requires client authentication for EST-coaps functions, while [RFC7030] permits certificate-less TLS authentication scenarios for EST when suitable shared credentials are available.

▲

Table of Contents

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 4 April 2027.

1. Introduction

Enrollment over Secure Transport (EST), defined in [RFC7030], provides certificate enrollment over a secure transport and places the EST server logically between a Certification Authority and the client, performing functions commonly associated with a Registration Authority. [RFC9148] defines EST-coaps, which transports EST payloads over secure CoAP using DTLS for constrained IoT environments.

[RFC9148] specifies certificate-based client authentication for EST-coaps, where EST-coaps client authentication is performed using a client certificate during the DTLS handshake. Devices that are already registered and operational may not possess a certificate suitable for EST-coaps client authentication. Such devices are therefore unable to use the certificate-based authentication model described in [RFC9148] for initial enrollment. This profile assumes that an external trust relationship between the device and the deployment ecosystem already exists before enrollment and that the device has been registered in an authoritative backend system.

This document defines a constrained profile in which such devices authenticate to the EST-coaps server by using a DTLS PSK authentication. The PSK is either the device-unique symmetric key itself or a derived key generated from that device-unique symmetric key using a cryptographically approved key derivation function. The EST-coaps server or registrar obtains the corresponding keying material from an authoritative device registry, or key management system using the PSK identity presented by the device.

This document does not modify EST enrollment semantics, certificate issuance procedures, proof-of-possession requirements, or certification authority policy. It defines an alternative EST-coaps authentication profile for devices that do not possess a certificate suitable for DTLS client authentication.

This profile is intended to complement, rather than replace, the certificate-based authentication model defined in RFC 9148. Implementations that support certificate-based EST-coaps authentication remain fully compliant without support for this profile.

This document only defines an alternative client authentication mechanism for the initial EST-coaps enrollment transaction.

2. Terminology

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.

The terminology from [RFC7030] and [RFC9148] applies. This document additionally defines the following terms:

Table 1: Definitions
Term Definition
Field Device A device that has already been deployed, registered, and is operational in a production network.
No Initial Certificate Device A fielded device that does not possess an IDevID, manufacturer certificate, birth certificate, or other certificate usable for the initial EST-coaps DTLS client authentication.
Device-Unique Symmetric Key A symmetric secret provisioned uniquely per device and known to an authoritative backend system.
PSK Identity An identifier sent by the device during the DTLS PSK handshake that allows the server to locate the corresponding device-unique key or derived PSK.
Derived Enrollment PSK A PSK derived from the device-unique symmetric key using a key derivation function and protocol-specific context.
Authoritative Device Registry A backend system, or key management service that binds each device identity to its unique symmetric key and authorization state.

3. Applicability Statement

This profile applies only when all of the following conditions are true:

  1. The device is already registered in an authoritative backend system.
  2. The device is already operational or has previously been authenticated by the deployment ecosystem.
  3. The device does not have an initial certificate suitable for DTLS client authentication.
  4. The device possesses a symmetric key that is unique to that device.
  5. The backend can securely retrieve or derive the same PSK material based on the received PSK identity.
  6. The goal is to obtain an operational certificate using EST or EST-coaps.

This profile is not intended for devices that share a common fleet-wide symmetric key, rather this profile is intended for devices that have already established trust relationships with the deployment ecosystem through prior registration or deployment-specific provisioning procedures.

3.1. Trust Assumptions

This profile assumes that each device has been provisioned with a symmetric key that is unique to that device and that the corresponding keying material is available to an authoritative backend system.

The mechanisms used to generate, provision, distribute, or protect the device-unique symmetric key are outside the scope of this document.

This profile further assumes that the backend system maintains an authoritative binding between the device identity, device status, and associated symmetric key material. The security of this profile depends on the integrity and confidentiality of that binding.

4. Security Constraints

4.1. Device-Unique Key Requirement

  • Each device MUST be provisioned with a symmetric key that is cryptographically unique to that device.
  • A symmetric key MUST NOT be shared across multiple devices, product batches, manufacturing lots, utility deployments, or customer environments.
  • A device-unique key MUST have sufficient entropy to resist offline guessing attacks. TLS 1.3 explicitly warns that low-entropy PSKs or password-derived PSKs are vulnerable to brute-force or dictionary attacks based on observable PSK binders.
  • If a derived enrollment PSK is used, it MUST be derived using a cryptographically approved KDF that includes protocol-specific context, device identity, intended use, and deployment-specific context to prevent cross-protocol and cross-environment key reuse. Implementations SHOULD use HKDF, as defined by [RFC5869], or an equivalent NIST-approved key derivation mechanism.

4.2. No Fleet-Wide PSK

A fleet-wide PSK MUST NOT be used. Compromise of a fleet-wide PSK would allow impersonation of all devices sharing that key and would prevent reliable attribution of enrollment requests to individual devices.

4.3. Device Identity Binding

The PSK identity MUST uniquely identify the device or uniquely identify a backend record that maps to one device.

The EST-coaps server or registrar MUST verify that:

  • the PSK identity maps to exactly one registered device.
  • the device is authorized for certificate enrollment.
  • the device has not been revoked, retired, replaced, or marked compromised.

The syntax and structure of the PSK identity are deployment specific and are outside the scope of this specification. This profile does not define a mandatory PSK identity format. Profiles or deployments adopting this specification MAY define a mandatory PSK identity format to ensure interoperability among participating implementations.

4.4. Key Storage

Device-unique symmetric keys MUST be stored in a protected device storage location appropriate to the device security profile.

Backend copies of device-unique keys SHOULD be protected using an HSM, KMS, or equivalent key protection service. Access to device keys MUST be audited and limited to services that require the key for enrollment authentication.

4.4.1. Backend Trust Model

The security of this profile depends upon the integrity, availability, and confidentiality of the authoritative device registry or key management system. The authoritative backend system MUST maintain a binding between device identity, enrollment status, lifecycle status and key material. Communication between the EST-coaps server or registrar and the authoritative backend system MUST be mutually authenticated and integrity protected. Access to device key material MUST be restricted to authorized services performing enrollment authentication functions. Deployments SHOULD ensure that device key retrieval, key usage, authorization decisions, enrollment approvals, and enrollment rejections are auditable. Unauthorized modification of backend device registrations can compromise enrollment authorization decisions. Deployments SHOULD therefore implement access controls, auditing, and change-management procedures appropriate for the operational environment.

4.5. Separation of Long-Term Device Key and DTLS PSK

The long-term device-unique key SHOULD NOT be used directly as the DTLS PSK. Implementations SHOULD derive a dedicated enrollment PSK from the device-unique key using a cryptographically approved key derivation function. Direct use of the long-term device-unique key SHOULD only be used when device constraints or deployment limitations prevent derivation of a dedicated enrollment credential.

DTLS PSK SHOULD be derived from the long-term device key using context such as:

Derived-Enrollment-PSK = KDF(DeviceUniqueKey, label = "EST-coaps initial enrollment PSK", context = DeviceIdentity || DeploymentId || ESTServerId || ProtocolVersion)

This separation reduces the risk that compromise or exposure of an enrollment PSK impacts other protocols or device functions.

5. Protocol Design

5.1. Protocol Layers

This profile uses the same layering model as EST-coaps, except that DTLS client authentication is performed using PSK authentication rather than a client certificate.

+------------------------------------------------+
|    EST request/response messages               |
+------------------------------------------------+
|    CoAP for message transfer and signaling     |
+------------------------------------------------+
|    DTLS with device-unique PSK authentication  |
+------------------------------------------------+
|    UDP                                         |
+------------------------------------------------+
Figure 5-1: EST-coaps PSK Protocol Layers

[RFC9148] defines EST-coaps as EST payloads over CoAP protected by DTLS, and it uses CoAP Block-Wise Transfer for large EST payloads to avoid IP fragmentation.

5.2. EST Functions

The following [RFC9148] EST-coaps functions remain applicable:

Table 2: EST-coaps Functions
EST Function EST-coaps Short URI This Profile
CA certificate retrieval /crts MUST support
Simple enrollment /sen MUST support
Simple re-enrollment /sren SHOULD support after operational certificate issuance
CSR attributes /att SHOULD support
Server-side key generation /skg or /skc NOT RECOMMENDED for this profile

[RFC9148] maps EST operations such as /cacerts, /simpleenroll, /simplereenroll, and /csrattrs to shorter EST-coaps URI paths such as /crts, /sen, /sren, and /att.

5.3. Enrollment Flow

A typical flow is:

  1. The device initiates a DTLS connection to the EST-coaps registrar or server.
  2. The device sends its PSK identity in the DTLS handshake. The PSK identity serves only as a lookup identifier and MUST NOT be treated as proof of device identity in the absence of successful PSK authentication.
  3. The server uses the PSK identity to query the authoritative device registry.
  4. The registry returns the device-specific PSK or sufficient material to derive it.
  5. The DTLS handshake completes PSK authentication.
  6. The device sends an EST /sen request containing a CSR.
  7. The EST-coaps server or registrar MUST verify that the authenticated PSK identity is authorized to obtain the certificate identifiers requested within the CSR Subject and Subject Alternative Name extensions. EST server MUST reject enrollment requests containing Subject or Subject Alternative Name values that are not associated with the authenticated device.
  8. The CA issues the operational certificate.
  9. After successful certificate enrollment, implementations SHOULD transition from PSK-based authentication to certificate-based authentication for subsequent EST operations, including re-enrollment. The PSK authentication mechanism defined in this profile is intended primarily for initial enrollment of devices that do not possess a suitable certificate for EST-coaps authentication.

6. DTLS Profile and Cipher Suite Recommendations

6.1. DTLS Version

Implementations SHOULD support DTLS 1.3 as specified in [RFC9147]. DTLS 1.3 is based on TLS 1.3 and provides equivalent security properties except for order protection and non-replayability differences inherent to datagram transport.

Implementations that require interoperability with existing constrained devices MAY support DTLS 1.2 as specified in [RFC6347]. [RFC9147] obsoletes [RFC6347], so DTLS 1.3 should be the preferred version for new implementations.

6.2. Recommended DTLS 1.3 Cipher Suite

For DTLS 1.3, the following cipher suite is RECOMMENDED:

TLS_AES_128_GCM_SHA256 or TLS_AES_256_GCM_SHA384

If the system uses PSK, implementations SHOULD use PSK with ephemeral Diffie-Hellman key establishment, also referred to as psk_dhe_ke, rather than PSK-only mode. TLS 1.3 allows PSKs to be used either alone or with (EC)DHE, and use with (EC)DHE provides forward secrecy while PSK-only does not.

Recommended DTLS 1.3 profile:

6.3. Recommended DTLS 1.2 Cipher Suite

For DTLS 1.2, the following cipher suites are RECOMMENDED:

TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 or TLS_DHE_PSK_WITH_AES_256_GCM_SHA384

As defined by [RFC5487], ECDHE-PSK cipher suites are RECOMMENDED to provide ephemeral key establishment, AEAD protection, and security characteristics appropriate for constrained environments.

Recommended DTLS 1.2 profile:

7. Authorization Requirements

Successful PSK authentication proves possession of the device’s symmetric key, but it does not by itself prove that the device should receive a certificate. Therefore, the EST-coaps server MUST perform authorization checks before forwarding or approving the CSR. If any authorization check defined in this section fails, the EST-coaps server or registrar MUST reject the enrollment request and MUST NOT forward the CSR to the Certification Authority.

Authorization checks described in this section are applied during the enrollment flow defined in Section 5.3. The authorization decision MUST include:

Table 3: Authorization Requirements
Check Requirement
Device registration PSK identity maps to a known registered device
Key uniqueness Device key is unique and not fleet-shared
Device state Device is active and not revoked, decommissioned, replaced, or compromised
CSR identity CSR subject and SAN values match the registered device identity
Certificate profile Requested certificate profile is allowed for that device class
Rate limit Enrollment attempts are rate limited per device identity and source
Audit Successful and failed enrollment attempts are logged

[RFC7030] states that the EST server is responsible for authenticating and authorizing the client before acting on the request, and that certificate issuance remains controlled by local CA policy.

8. Proof-of-Possession

The device MUST generate the key pair for the requested operational certificate unless server-side key generation is explicitly required by deployment policy.

The CSR MUST include proof-of-possession by signing the CSR with the private key corresponding to the public key being certified. [RFC7030] describes proof-of-possession and linking identity to proof-of-possession using TLS channel binding information.

For DTLS 1.2, implementations SHOULD bind the CSR to the authenticated DTLS session using the applicable channel-binding approach.

For DTLS 1.3, implementations SHOULD use exporter-based channel binding where supported, since [RFC9148] notes that TLS 1.3 lacks the same tls-unique channel binding used in earlier TLS versions and discusses use of exporter-derived binding for TLS 1.3 contexts.

9. Deployment Limitations

This profile has the following limitations:

  1. Initial trust depends on the secrecy and uniqueness of the symmetric device key.
  2. Compromise of a device-unique key permits impersonation of that device until the key or device record is revoked.
  3. The PSK identity may expose information about the device if it contains a serial number, asset identifier, meter identifier, IMEI, MAC address, or another deployment-specific identifier.
  4. Backend key lookup introduces dependency on the availability and security of the authoritative device registry.
  5. This profile does not bootstrap unknown devices.
  6. This profile does not remove the need for normal PKI validation after the operational certificate is issued.

10. Security Considerations

10.1. Unique Symmetric Keys Are Mandatory

The strongest security constraint in this profile is that every device MUST have a unique symmetric key. A common or fleet-shared key would allow one compromised device to impersonate other devices and would defeat per-device authorization.

10.2. PSK Entropy

PSKs and device-unique symmetric keys MUST be generated with sufficient randomness. TLS 1.3 warns that low-entropy out-of-band PSKs are vulnerable to brute-force attacks and that PSK authentication is not a strong password-authenticated key exchange.

10.3. Forward Secrecy

DTLS 1.3 PSK-only mode SHOULD NOT be used for enrollment because it does not provide forward secrecy. DTLS 1.3 PSK with ECDHE SHOULD be used where supported.

10.4. Replay and DoS Protection

DTLS includes mechanisms for datagram environments, including retransmission handling, handshake fragmentation, and replay detection. DTLS 1.2 uses sequence numbers and optional replay detection, and DTLS 1.3 similarly addresses packet loss, reordering, fragmentation, and replay detection.

Servers SHOULD enable DTLS anti-replay protections and MUST rate limit failed PSK handshakes and failed enrollment attempts.

10.5. No 0-RTT Enrollment

Enrollment requests MUST NOT be sent using DTLS 1.3 0-RTT data. TLS 1.3 0-RTT data has weaker security properties and can be replayed across connections.

10.6. Backend Key Retrieval

The EST-coaps registrar or server MUST authenticate to the backend system before retrieving device key material. Backend responses MUST be integrity protected and confidential. Key retrieval events MUST be auditable.

10.7. Transition to Certificate-Based Authentication

After successful certificate issuance, the device SHOULD use the issued operational certificate for future EST re-enrollment and other certificate-authenticated network access. This aligns with the existing EST and EST-coaps model where certificates are used for later authentication.

Continued use of PSK authentication after issuance of an operational certificate may unnecessarily extend reliance on shared-secret authentication mechanisms. Where practical, deployments SHOULD transition to certificate-based authentication following successful enrollment.

10.8. Device Credential Revocation

Deployments MUST provide a mechanism to disable, revoke, or otherwise invalidate device credentials when a device is determined to be compromised, replaced, retired, or no longer authorized.

The EST-coaps server or registrar MUST reject enrollment requests originating from devices whose associated credentials have been revoked or disabled within the authoritative device registry.

Revocation events SHOULD be auditable and propagated in a timely manner to all systems responsible for enrollment authorization decisions.

11. IANA Considerations

This draft does not initially require new IANA registrations if it reuses existing EST-coaps resources, CoAP content formats, and DTLS cipher suites.

Future revisions of this specification may define a new discovery resource type or EST-coaps profile indicator.

12. References

12.1. Normative References

[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>.
[RFC5487]
Eronen, P. and H. Tschofenig, "Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode", , <https://www.rfc-editor.org/info/rfc5487>.
[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>.
[RFC6347]
Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, , <https://www.rfc-editor.org/info/rfc6347>.
[RFC7030]
Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, , <https://www.rfc-editor.org/info/rfc7030>.
[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>.
[RFC9147]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, , <https://www.rfc-editor.org/info/rfc9147>.
[RFC9148]
van der Stok, P., Kampanakis, P., Richardson, M., and S. Raza, "EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol", RFC 9148, DOI 10.17487/RFC9148, , <https://www.rfc-editor.org/info/rfc9148>.

12.2. Informative References

[NIST.SP.800-108]
Technology, N. I. O. S. A., "Recommendation for Key Derivation Using Pseudorandom Functions", NIST Special Publication 800-108, , <https://csrc.nist.gov/publications/detail/sp/800-108/final>.

Authors' Addresses

Narinder Mittal
Landis+Gyr
Chris Hett
Landis+Gyr