Landis+Gyr

narinder.mittal@landisgyr.com

Landis+Gyr

chris.hett@landisgyr.com

Security EST EST-coaps DTLS PSK Certificate Enrollment 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. defines EST over secure CoAP and requires client authentication for EST-coaps functions, while permits certificate-less TLS authentication scenarios for EST when suitable shared credentials are available.

Table of Contents

• .  Introduction
• .  Terminology
• .  Applicability Statement
  • .  Trust Assumptions
• .  Security Constraints
  • .  Device-Unique Key Requirement
  • .  No Fleet-Wide PSK
  • .  Device Identity Binding
  • .  Key Storage
    • .  Backend Trust Model
  • .  Separation of Long-Term Device Key and DTLS PSK
• .  Protocol Design
  • .  Protocol Layers
  • .  EST Functions
  • .  Enrollment Flow
• .  DTLS Profile and Cipher Suite Recommendations
  • .  DTLS Version
  • .  Recommended DTLS 1.3 Cipher Suite
  • .  Recommended DTLS 1.2 Cipher Suite
• .  Authorization Requirements
• .  Proof-of-Possession
• .  Deployment Limitations
• .  Security Considerations
  • .  Unique Symmetric Keys Are Mandatory
  • .  PSK Entropy
  • .  Forward Secrecy
  • .  Replay and DoS Protection
  • .  No 0-RTT Enrollment
  • .  Backend Key Retrieval
  • .  Transition to Certificate-Based Authentication
  • .  Device Credential Revocation
• .  IANA Considerations

Introduction Enrollment over Secure Transport (EST), defined in , 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. defines EST-coaps, which transports EST payloads over secure CoAP using DTLS for constrained IoT environments. 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 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.

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 when, and only when, they appear in all capitals. The terminology from and applies. This document additionally defines the following terms: 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.

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.

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.

Security Constraints

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 , or an equivalent NIST-approved key derivation mechanism.

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.

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.

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.

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.

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.

Protocol Design

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-coaps PSK Protocol Layers +------------------------------------------------+ | EST request/response messages | +------------------------------------------------+ | CoAP for message transfer and signaling | +------------------------------------------------+ | DTLS with device-unique PSK authentication | +------------------------------------------------+ | UDP | +------------------------------------------------+

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.

EST Functions The following EST-coaps functions remain applicable: 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

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

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.

DTLS Profile and Cipher Suite Recommendations

DTLS Version Implementations SHOULD support DTLS 1.3 as specified in . 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 . obsoletes , so DTLS 1.3 should be the preferred version for new implementations.

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: DTLS 1.3 Key Exchange Mode: psk_dhe_ke Cipher Suite: TLS_AES_128_GCM_SHA256 Alternative: TLS_AES_256_GCM_SHA384 Group: X25519 or secp256r1 0-RTT: MUST NOT be used for enrollment requests

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 , 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: DTLS 1.2 Cipher Suite: TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 Alternative: TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 Group: secp256r1; X25519 where supported Compression: MUST NOT be used Renegotiation: MUST NOT be used for enrollment

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 . The authorization decision MUST include: 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

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.

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. 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 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.

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.

Security Considerations

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.

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.

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.

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.

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.

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.

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.

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.

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.

References Normative References 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. This document defines three new cipher suites for the Transport Layer Security (TLS) protocol that use pre-shared keys (PSKs) with AES in Galois/Counter Mode (GCM). These cipher suites provide authenticated encryption with associated data (AEAD) and use SHA-256 or SHA-384 for pseudorandom function operations. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [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. 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. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. Consultant Cisco Systems Sandelman Software Works RISE Research Institutes of Sweden 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. Informative References

Authors' Addresses Landis+Gyr

narinder.mittal@landisgyr.com

Landis+Gyr

chris.hett@landisgyr.com