]> Red Hat, Inc.

abokovoy@redhat.com

Red Hat, Inc.

jrische@redhat.com

Cryptonector

nico@cryptonector.com

Security Common Authentication Technology Next Generation Kerberos PKINIT post-quantum ML-KEM ML-DSA KEM This document specifies extensions to the Kerberos PKINIT pre-authentication mechanism to support post-quantum key establishment using the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) algorithms defined in . The extensions define a new kemInfo arm in PA-PK-AS-REP, a KDCKEMInfo structure signed by the KDC, HKDF-based AS reply key derivation (HKDF-SHA-512 for ML-KEM), downgrade-prevention rules, and a PAChecksum2 extension providing checksum algorithm agility in PKAuthenticator. The KEM path framework supports multiple KEM algorithms including ML-KEM, composite ML-KEM algorithms, and future KEM standards. Discussion Venues Discussion of this document takes place on the Common Authentication Technology Next Generation Working Group mailing list (kitten@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Kerberos PKINIT pre-authentication mechanism relies on public-key cryptography for initial authentication. The Diffie-Hellman and RSA paths it defines are vulnerable to a cryptographically relevant quantum computer. adds Elliptic Curve Diffie-Hellman (ECDH) support and adds algorithm agility, but neither addresses the quantum threat. This document defines a new KEM path in PKINIT that uses Key Encapsulation Mechanism (KEM) algorithms, in particular the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) . Rather than agreeing on a shared secret via a DH exchange, the client generates an ephemeral KEM key pair and sends the encapsulation key in a CMS-signed AuthPack ( Section 5). The KDC encapsulates against it, signs the ciphertext and algorithm selection in KDCKEMInfo, and returns the signed structure. Both parties derive the AS reply key using HKDF (). The design preserves the security properties of the RFC 4556 DH path (the client's ephemeral key is authenticated by the client's signing certificate; the KDC's response is authenticated by the KDC's signing certificate) while providing post-quantum forward secrecy through ML-KEM. This document also defines PAChecksum2, an extension to PKAuthenticator that provides checksum algorithm agility, supplementing the SHA-1-only paChecksum field of RFC 4556 for new deployments.

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

Protocol Overview The KEM path is activated when AuthPack.clientPublicValue contains an ML-KEM or composite ML-KEM OID. The exchange proceeds as follows:

1. The client generates an ephemeral KEM key pair, places the encapsulation key in AuthPack.clientPublicValue, and sends a signed AuthPack in PA-PK-AS-REQ.
2. The KDC verifies the AuthPack signature, encapsulates against the client's encapsulation key to obtain a shared secret ss and ciphertext kemct, signs them in a KDCKEMInfo structure, and returns PA-PK-AS-REP.kemInfo.
3. The client verifies the KDC signature, decapsulates to recover ss, and both parties derive the AS reply key using HKDF-SHA-512 over PkinitKEMSuppPubInfo.

No DH exchange takes place. The shared secret is established entirely through one-sided encapsulation; freshness is provided by the per-request ephemeral key pair and the echoed nonce.

KEM Algorithm Interface This specification uses the following generic KEM algorithm interface: Encap(ek) → (ss, ct): Takes an encapsulation key ek and returns a shared secret ss and ciphertext ct. Decap(dk, ct) → ss: Takes a decapsulation key dk and ciphertext ct and returns the shared secret ss. For ML-KEM (), these correspond to: - Encap(ek) = ML-KEM.Encaps(ek) (FIPS 203 Algorithm 17) - Decap(dk, ct) = ML-KEM.Decaps(dk, ct) (FIPS 203 Algorithm 18) The notation Encap() and Decap() is used throughout this document to describe the generic KEM path protocol. When implementing ML-KEM specifically, use the FIPS 203 algorithms. Future specifications extending this framework to other KEM algorithms MUST define their mapping to this interface.

Algorithm Identifier Encoding The parameters field MUST be absent from all algorithm identifiers used in this specification. The source of this requirement differs by algorithm family: (a) ML-KEM and ML-DSA identifiers (, ): the algorithm parameter set is fully encoded in the OID; no parameters field is defined. Applies to: (b) HKDF identifiers ( Section 3): the OID id-alg-hkdf-with-sha512 has absent parameters by definition. Only SHA-512 is defined for the KEM path (). Applies to:

New ASN.1 Types

Extended PA-PK-AS-REP uses an IMPLICIT TAGS module environment. All three arms are IMPLICIT OCTET STRING carrying DER-encoded structures; receivers identify the chosen arm by the context tag alone. The field name dhSignedData matches RFC 4556's actual ASN.1 module; the informal name dhInfo used in some descriptions refers to the same arm. Tag [2] MUST be verified against the IANA Kerberos PKINIT Parameters registry before publication to confirm no other extension has claimed it.

KEMRepInfo eContent in kemSignedData MUST be present (detached signatures are prohibited).

KDCKEMInfo kemAlgorithm makes KDCKEMInfo self-describing and provides signed confirmation that the KDC processed the correct algorithm (verified in step 4), avoiding implicit inference from kemct length alone.

Extended AuthPack

PkinitKEMSuppPubInfo

PAChecksum2 Extension hardwires the paChecksum field in PKAuthenticator to use SHA-1. Section 3 acknowledges this limitation but does not provide a mechanism to negotiate alternative checksum algorithms, noting that for DH and ECDH paths the KDF binding (which includes the entire AS-REQ in key derivation) provides an eventual integrity check. This specification extends PKAuthenticator with a paChecksum2 field to provide checksum algorithm agility at the request validation layer. PAChecksum2 was first defined in §2.2.3 (PA-PK-AS-REQ). The PKAuthenticator structure from is extended as follows:

Client behavior:

A client constructing a PKINIT request conforming to this specification MUST include the paChecksum2 field and SHOULD include the paChecksum field (SHA-1, per ). Both checksums, when present, are computed over the same KDC-REQ-BODY input.

KDC validation:

A KDC conforming to this specification MUST require paChecksum2 to be present in the request. If paChecksum2 is absent, the KDC returns KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (error code 79, ). The KDC MUST validate paChecksum2. If paChecksum is also present, the KDC MUST validate it as well. The KDC returns the following errors:

• KDC_ERR_SUMTYPE_NOSUPP (error code 15, ): if the digest algorithm in paChecksum2.algorithmIdentifier is not supported by the KDC.
• KRB_AP_ERR_MODIFIED (error code 41, ): if verification of paChecksum2 fails, or if paChecksum is present and its verification fails.

Mode Selection The exchange mode is determined by the algorithm OID in clientPublicValue: Mode selection by clientPublicValue OID

clientPublicValue	OID type	Mode
Absent	—	RSA path (encKeyPack); deprecated for new deployments
Present	DH or ECDH OID	DH/ECDH path ( / )
Present	ML-KEM or composite ML-KEM OID	KEM path (this specification)
Present	Unrecognized OID	Error (see ); MUST NOT fall back to RSA path

For the pure KEM path defined in this specification, when clientPublicValue contains a KEM OID and clientDHNonce is also present, the KDC MUST return KDC_ERR_PREAUTH_FAILED. Future hybrid DH+KEM specifications may define different nonce semantics and relax this requirement. When present, supportedKDFs MUST contain only KDFs applicable to the path indicated by clientPublicValue.algorithm: HKDF algorithm OIDs () for the KEM path, or DH-KDF algorithm OIDs per for the DH/ECDH path.

KEM Path Operation

Client Request Construction

1. Generate a fresh ephemeral KEM key pair (ek, dk) for the chosen algorithm using a cryptographically secure pseudorandom number generator (CSPRNG). The security of the KEM path depends entirely on the unpredictability of dk (for ML-KEM CSPRNG requirements, see ).
2. Encode ek as SubjectPublicKeyInfo and place it in AuthPack.clientPublicValue. parameters MUST be absent. For ML-KEM, encoding follows .
3. Set supportedKDFs to { id-alg-hkdf-with-sha512 }. If omitted, HKDF-SHA-512 is assumed.
4. Wrap AuthPack as the eContent of a CMS SignedData ( Section 5) per Section 3.2.2 and sign with the client's signing certificate. For full quantum resistance, the client SHOULD use an ML-DSA certificate (); traditional ECDSA and RSA certificates are permitted during the transition period.

The ephemeral encapsulation key ek is authenticated by the client's signing certificate via AuthPack.SignedData ( Section 5.2), following the DH path model. No separate encapsulation certificate is required.

KDC Response Construction

1. Detect the KEM algorithm OID in clientPublicValue.algorithm.
2. Check whether the algorithm is supported and meets the KDC's security policy (per Section 3.2.2): a. If the algorithm OID is not recognized or not implemented, return KDC_ERR_EPHEMERAL_KEY_PARAMS_NOT_ACCEPTED (error code 65) with TD-EPHEMERAL-KEY-PARAMETERS-DATA listing supported algorithms; stop. b. If the algorithm does not satisfy the KDC's security policy, return KDC_ERR_EPHEMERAL_KEY_PARAMS_NOT_ACCEPTED (error code 65) with TD-EPHEMERAL-KEY-PARAMETERS-DATA listing acceptable algorithms; stop.
3. Select a KDF from supportedKDFs that is approved for the KEM algorithm (see ). If supportedKDFs is absent, default to id-alg-hkdf-with-sha512. If no approved KDF can be selected, return KDC_ERR_NO_ACCEPTABLE_KDF (error code 100, ); stop.
4. Call Encap(ek) → (ss, kemct) using the selected algorithm (see ). Exactly one encapsulation MUST be performed per exchange; the resulting (ss, kemct) pair MUST be used in all subsequent steps (for ML-KEM specifics, see ).
5. Build KDCKEMInfo:
   • kemAlgorithm = OID from clientPublicValue.algorithm (echoed back)
   • kemct = the ciphertext from step 4
   • kdfAlgorithm = selected HKDF OID
   • nonce = pkAuthenticator.nonce from the client's request (SHOULD be included; see )
6. Sign KDCKEMInfo using CMS SignedData ( Section 5) with ML-DSA () RECOMMENDED. Place in kemSignedData. eContent MUST be present. Step 7 MUST follow step 6 because PkinitKEMSuppPubInfo.kemSignedData is set to the DER encoding of KEMRepInfo.kemSignedData produced in this step.
7. Derive the AS reply key from ss per . The KDC uses it to encrypt the AS-REP enc-part.
8. Return PA-PK-AS-REP.kemInfo containing KEMRepInfo.

Client Response Processing The client MUST perform the following steps in order. On any abort the client MUST erase dk before returning.

1. Verify KDC signature over kemSignedData. Abort if invalid.
2. Verify serverNonce is absent: KDCKEMInfo.serverNonce MUST NOT be present in pure ML-KEM exchanges defined by this specification. Abort if present.
3. Extract and verify nonce: If KDCKEMInfo.nonce is present, it MUST equal pkAuthenticator.nonce. Abort if not. If absent, implementations MUST verify freshness through alternative means (e.g., timestamp in PKAuthenticator); future KEM specifications MUST define which mechanism applies when nonce is omitted.
4. Verify echoed algorithm: KDCKEMInfo.kemAlgorithm MUST exactly match the algorithm OID in the client's own clientPublicValue.algorithm. Abort if they differ. This confirms the KDC did not substitute a different algorithm.
5. Validate kemct length: the byte length of KDCKEMInfo.kemct MUST match the fixed ciphertext size for KDCKEMInfo.kemAlgorithm (see for ML-KEM sizes). Abort if not. KEM algorithms MUST NOT be called on incorrectly-sized ciphertexts.
6. Decapsulate: ss = Decap(dk, KDCKEMInfo.kemct) using the algorithm in KDCKEMInfo.kemAlgorithm. Erase dk immediately after this call completes, before any further processing.
7. Derive reply key from ss per . Use this key to decrypt the AS-REP enc-part.
8. Confirm dk erasure. The ephemeral decapsulation key MUST have been erased in step 6 and MUST NOT be retained.

Steps 1–5 MUST complete before step 6. Decapsulation MUST NOT be called on an unauthenticated ciphertext.

KDC Certificate Validation The KDC certificate validation rules of Section 3.2.3 apply unchanged to kemSignedData. The client uses the same trust anchors and validation procedure as for the DH path.

AS Reply Key Derivation

HKDF OIDs The KEM path uses 's KDF negotiation mechanism via supportedKDFs. For ML-KEM and composite ML-KEM, this specification approves only HKDF-SHA-512: Approved KDFs for ML-KEM

OID	Hash	Conformance for ML-KEM
id-alg-hkdf-with-sha512	SHA-512	MUST implement

When clientPublicValue.algorithm contains an ML-KEM or composite ML-KEM OID, the KDC selects a KDF from supportedKDFs that appears in the approved list above. If supportedKDFs is absent or contains no approved KDF, the KDC defaults to id-alg-hkdf-with-sha512.

Derivation , -- defaults to HashLen zero bytes (RFC 5869 Section 2.2); -- ss is uniformly random so extraction is unnecessary info = DER(PkinitKEMSuppPubInfo), L = ) reply_key = random-to-key(reply_key_material) -- per RFC 3961 Section 3 ]]> L is the random-to-key input string length for the Kerberos enctype in PkinitKEMSuppPubInfo.enctype, as defined in the enctype's specification: random-to-key input lengths by enctype

Enctype	L
aes128-cts-hmac-sha256-128 ()	16 bytes
aes256-cts-hmac-sha384-192 ()	32 bytes

For these enctypes random-to-key is the identity function. Other enctypes use the key-generation seedlength from their crypto profile. PkinitKEMSuppPubInfo.kemSignedData is set to DER(KEMRepInfo.kemSignedData): the KDC-signed KDCKEMInfo only, not the full PA-PK-AS-REP. This avoids a circular dependency: the full response cannot be included in the context used to derive the key that protects it. The value reply_key produced by this derivation IS the AS reply key used to encrypt the Kerberos AS-REP enc-part. Both the KDC and the client independently derive the same value from ss using the KDF algorithm and context recorded in PkinitKEMSuppPubInfo. The reply key is never transmitted; both parties arrive at it through independent computation.

Error Handling

Proactive Advertisement A KDC SHOULD include TD-EPHEMERAL-KEY-PARAMETERS-DATA in KDC_ERR_PREAUTH_REQUIRED to allow the client to select an acceptable algorithm on its first attempt. This avoids a retry round trip, which is particularly valuable for post-quantum deployments where both ML-DSA signatures and ML-KEM encapsulation keys are significantly larger than their traditional counterparts, making the overhead of a failed attempt much higher.

Ephemeral Key Parameter Errors When the algorithm and parameter set in clientPublicValue.algorithm does not satisfy the KDC's security policy, the KDC returns: This error code is a renamed and expanded version of KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED from , which already covers DH () and ECDH (). The error code number (65) is reused; this specification extends the scope to also cover ML-KEM and composite ML-KEM. This error is returned when:

• The algorithm OID is not recognized or not implemented by the KDC
• The algorithm does not meet the KDC's security requirements

The KDC SHOULD include TD-EPHEMERAL-KEY-PARAMETERS-DATA (as defined in ) in the error response. After receiving this error, the client follows Section 3.2.2 retry behavior, selecting a different parameter set from TD-EPHEMERAL-KEY-PARAMETERS-DATA that satisfies the client's security policy. If no mutually acceptable parameter set exists, the exchange MUST be terminated.

KEM Path Errors When clientPublicValue contains a KEM OID, the KDC MUST NOT return DH digest negotiation errors (KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED, KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED). The only applicable error for parameter negotiation failure on the KEM path is KDC_ERR_EPHEMERAL_KEY_PARAMS_NOT_ACCEPTED ().

Downgrade Prevention When a client uses a post-quantum certificate (e.g., ML-DSA per , composite ML-DSA per , or future quantum-resistant signature algorithms) and sends a post-quantum KEM encapsulation key (ML-KEM or composite ML-KEM) in clientPublicValue, the client MUST NOT fall back to traditional key-establishment algorithms (DH, ECDH, RSA). This ensures quantum-resistant authentication and key establishment are paired. The client MAY retry with a different post-quantum KEM algorithm from . If no post-quantum KEM is available, the client MUST fail the authentication attempt. Clients using traditional certificates (RSA, ECDSA) MAY fall back from post-quantum KEM to traditional key establishment (DH, ECDH) for backward compatibility with non-upgraded KDCs. The security considerations regarding unauthenticated error messages in Section 5 apply.

Algorithm Requirements

KEM Algorithms

Pure ML-KEM Algorithms Pure ML-KEM algorithm requirements

Algorithm	OID	NIST Category	Conformance
ML-KEM-512	2.16.840.1.101.3.4.4.1	1	MAY
ML-KEM-768	2.16.840.1.101.3.4.4.2	3	MUST implement
ML-KEM-1024	2.16.840.1.101.3.4.4.3	5	SHOULD

Composite ML-KEM Algorithms Composite ML-KEM algorithm requirements

Algorithm	OID	NIST Category	Conformance
id-MLKEM768-ECDH-P256-SHA3-256	1.3.6.1.5.5.7.6.59	3	SHOULD
id-MLKEM768-X25519-SHA3-256	1.3.6.1.5.5.7.6.58	3	MAY
id-MLKEM1024-ECDH-P384-SHA3-256	1.3.6.1.5.5.7.6.63	5	SHOULD

Composite algorithms are defined in .

Client Algorithm Selection As with DH path algorithm selection, the client selects which KEM algorithm to use based on local policy. Algorithm selection is implementation-defined. If the client receives proactive advertisement () and supports none of the advertised algorithms, it MUST fail the authentication attempt rather than trying an unadvertised algorithm.

KDC Security Policy As with Section 3.2.2, the KDC enforces a security policy for ephemeral key algorithms. The specific policy is implementation-defined. For ML-KEM, implementations MAY use NIST security categories as a basis for policy decisions: NIST security categories for ML-KEM

Category	Algorithm	Post-quantum bit security
1	ML-KEM-512	128 bits
3	ML-KEM-768	192 bits
5	ML-KEM-1024	256 bits

NIST recommends ML-KEM-768 (Category 3) as the default parameter set, as it provides a large security margin at a reasonable performance cost. Composite parameter sets combining ML-KEM with traditional algorithms provide the security category of their ML-KEM component for post-quantum resistance.

RSA Path Deprecation The encKeyPack [1] path is quantum-vulnerable. New deployments SHOULD NOT use encKeyPack. Existing deployments MAY continue using it for traditional compatibility during migration.

Message Size Considerations An AuthPack with an ephemeral ML-KEM-768 encapsulation key (1184 bytes, see ) signed with ML-DSA-65 (3309-bytes signature ) will exceed UDP datagram limits. TCP transport () is REQUIRED for ML-KEM PKINIT. All Kerberos infrastructure (KDCs, clients, firewalls) MUST support TCP Kerberos before enabling ML-KEM PKINIT.

ML-KEM-Specific Considerations This section captures behavior specific to ML-KEM (). When this specification is extended to other KEM algorithms, per-algorithm sections following this structure SHOULD be added. The core protocol defined in through is intentionally algorithm-agnostic; ML-KEM details are isolated here following the model of .

Key and Ciphertext Sizes All sizes are fixed by ; no variability is permitted. ML-KEM fixed key and ciphertext sizes

Algorithm	Encapsulation key	Ciphertext	Shared secret
ML-KEM-512	800 bytes	768 bytes	32 bytes
ML-KEM-768	1184 bytes	1088 bytes	32 bytes
ML-KEM-1024	1568 bytes	1568 bytes	32 bytes

The client MUST validate KDCKEMInfo.kemct length against these values before calling Decapsulate ( step 5). does not define behavior for ML-KEM.Decaps on incorrectly-sized input.

CSPRNG Requirement Both ML-KEM key generation and encapsulation MUST use a cryptographically secure pseudorandom number generator (CSPRNG) satisfying the requirements of Section 3.3. The security of the KEM path depends on:

• Client-side: the unpredictability of the ephemeral decapsulation key dk during key generation.
• KDC-side: the unpredictability of the randomness used during ML-KEM.Encaps(ek), which produces the shared secret ss and ciphertext kemct.

A weak or predictable RNG on either side compromises the AS reply key.

Encapsulation and Decapsulation

KDC:

(ss, kemct) = ML-KEM.Encaps(ek) per step 4.

Client:

ss = ML-KEM.Decaps(dk, kemct) per step 6, followed by immediate dk erasure.

The shared secret ss is 32 bytes for all three ML-KEM variants.

Security Considerations

Quantum Resistance The KEM path achieves post-quantum confidentiality only when both the KEM algorithm and the KDC signing algorithm are quantum-resistant. Using ML-KEM with a traditional ECDSA or RSA signing certificate provides PQC key establishment but not PQC authentication; an adversary with a quantum computer could impersonate the KDC by forging its traditional signature. Deployers seeking full quantum resistance MUST use ML-DSA () or a composite ML-DSA variant () for KDC signing.

Ephemeral Decapsulation Key Hygiene The ephemeral decapsulation key dk MUST be erased as soon as decapsulation completes ( step 6). Failure to erase dk negates forward secrecy: an attacker who later recovers dk can recompute ss and derive the AS reply key for any recorded exchange that used the corresponding ek.

Authenticated KDF Inputs leaves the KDF algorithm unprotected: a man-in-the-middle could modify the kdfAlgorithm field before the client processes the response. This specification places kdfAlgorithm inside the KDC-signed KDCKEMInfo, making it authenticated. Clients MUST NOT derive a reply key using an algorithm not present in the signed structure.

Unauthenticated Error Messages The security considerations in Section 5 regarding unauthenticated KRB-ERROR messages apply to TD-EPHEMERAL-KEY-PARAMETERS-DATA. Clients MUST enforce their configured security policy regardless of advertised algorithms.

Algorithm Downgrade Prevention The downgrade prevention rules in are mandatory and unconditional. A client that allows a fallback from the KEM path to the DH/RSA path on receiving a traditional response exposes the session to an active attacker who can exploit a traditional-path vulnerability.

paChecksum2 and Replay Prevention paChecksum2 binds the KDC-REQ-BODY to the authenticator using a quantum-safe digest. Implementations MUST NOT accept requests in which paChecksum2 is absent when operating in KEM mode, as defined in .

Nonce Generation The nonce in PKAuthenticator provides replay protection. Implementations MUST generate nonces from a Deterministic Random Bit Generator (DRBG) approved by . Counter-based or predictable nonces compromise replay protection.

IANA Considerations

New Kerberos Error Code IANA is requested to assign a new Kerberos Message Error Code in the "Kerberos Message Error Codes" sub-registry of the "Kerberos Parameters" registry: Renamed Kerberos error code

Value	Old Name	New Name	Reference
65	KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED	KDC_ERR_EPHEMERAL_KEY_PARAMS_NOT_ACCEPTED	, This document

New PKINIT OID IANA is requested to assign a new object identifier under the PKINIT OID arc (id-pkinit, 1.3.6.1.5.2.3) in the "SMI Security for PKIX Module Identifier" registry: New PKINIT OID assignment

Decimal	Description	Reference
TBD	id-pkinit-KEMKeyData	This document

Update to Kerberos Pre-Authentication Data Types Registry IANA is requested to update the description of the existing entry for TD-DH-PARAMETERS in the "Kerberos Pre-Authentication Data Types" sub-registry of the "Kerberos Parameters" registry:

Old description:

"Typed data for KDC_ERR_KEY_TOO_WEAK; contains a list of acceptable Diffie-Hellman algorithm identifiers."

New name and description:

TD-EPHEMERAL-KEY-PARAMETERS, "Typed data for KDC_ERR_EPHEMERAL_KEY_PARAMS_NOT_ACCEPTED and KDC_ERR_KEY_TOO_WEAK; contains a list of acceptable ephemeral key-establishment algorithm identifiers, including DH, ECDH, ML-KEM, and composite ML-KEM algorithms."

The integer value and ASN.1 encoding (SEQUENCE OF AlgorithmIdentifier) are unchanged. No new integer allocation is required.

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. 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 describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement". [STANDARDS-TRACK] This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. [STANDARDS-TRACK] This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields. [STANDARDS-TRACK] This document describes an extensibility mechanism for the Kerberos V5 protocol when used over TCP transports. The mechanism uses the reserved high-bit in the length field. It can be used to negotiate TCP-specific Kerberos extensions. [STANDARDS-TRACK] This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT -- the Kerberos Version 5 extension that provides for the use of public key cryptography. This memo provides information for the Internet community. 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 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 is not an Internet Standards Track specification; it is published for informational purposes. This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. RFC 5869 specifies the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions. This document updates the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) standard (RFC 4556) to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide preemptive protection against vulnerabilities discovered in the future in any specific cryptographic algorithm and allow incremental deployment of newer algorithms. Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) is a quantum-resistant Key Encapsulation Mechanism. This document specifies the conventions for using the ML-KEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also specified. National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) Informative References The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined by NIST in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier syntax is provided. Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST ML-KEM in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-KEM is applicable in any application that uses X.509 or PKIX data structures that accept ML- KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines in certain regions. Composite ML-DSA is applicable in applications that use X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where existential unforgeability (EUF-CMA) level security is acceptable. Microsoft Corporation

Acknowledgements The authors thank the IETF KITTEN and LAMPS working groups for discussion of post-quantum PKINIT approaches, and the NIST team for and .