How to test post-quantum Kerberos PKINIT

Also mentioned

RSARSARivest, Shamir and AdlemanA widely used public-key algorithm for encryption and digital signatures whose security relies on the difficulty of factoring large numbers.Read the full entry (new tab), ECDHECDHElliptic Curve Diffie-HellmanElliptic Curve Diffie-Hellman, a key-exchange method using elliptic-curve mathematics to establish a shared secret with smaller keys than classical Diffie-Hellman.Read the full entry (new tab), ECDSAECDSAElliptic Curve Digital Signature AlgorithmElliptic Curve Digital Signature Algorithm, a widely deployed signature scheme based on elliptic-curve cryptography, offering strong security with compact keys.Read the full entry (new tab), ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry (new tab), ML-DSAML-DSAModule-Lattice-based Digital Signature AlgorithmModule-Lattice-Based Digital Signature Algorithm, the NIST-standardized post-quantum signature scheme derived from CRYSTALS-Dilithium and specified in FIPS 204.Read the full entry (new tab), KEMKEMkey encapsulation mechanismA public-key mechanism for securely establishing a shared secret key: the sender encapsulates a random secret to the recipient's public key, and the recipient decapsulates it with their private key.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab), PQCPQCpost-quantum cryptographyCryptographic algorithms designed to run on today's classical computers while remaining secure against attacks by both classical and future quantum computers.Read the full entry (new tab), PKIPKIpublic key infrastructurePublic Key Infrastructure, the framework of certificate authorities, certificates, and policies that binds public keys to identities and enables trust in TLS, code signing, and email.Read the full entry (new tab) are defined in the glossary.

TL;DR

Read this first

A post-quantum PKINIT trial must prove more than ML-KEM decapsulation. Pin the exact Internet-Draft revision, authenticate the client's ephemeral KEM key and the KDC ciphertext, exercise certificate validation, verify HKDF negotiation and downgrade rules, then run the exchange over the real TCP path. The current ML-KEM PKINIT proposal is an active Internet-Draft and candidate for working-group adoption, not an IETF standard.

PKINIT lets Kerberos use public-key credentials during initial authentication. The current standard supports signed pre-authentication data and traditional Diffie-Hellman or RSA paths. A proposal published on 30 September 2026 adds a Key Encapsulation Mechanism path built around ML-KEM. That changes the message flow, key derivation, fallback policy and transport assumptions at the same time.

Treat the proposal as a test target, not a production profile. Record the exact draft revision, Kerberos client and KDC builds, certificate profiles, KDF identifiers and transport configuration in the cryptographic inventory. Link each result to a named control in the PQC migration roadmap so an experimental success cannot silently become a deployment approval.

Map the proposed exchange before testing it

In the proposed KEM path, the client creates an ephemeral ML-KEM key pair and places the encapsulation key in the signed AuthPack. The KDC validates the client signature and certificate, encapsulates to that key, and returns a ciphertext inside a KDC-signed KDCKEMInfo structure. Both sides derive the AS reply key from the shared secret with an agreed HKDF. The signatures bind identity and protocol context; ML-KEM establishes the secret.

Checkpoint	Evidence to capture	Required failure
Client request	Signed AuthPack, ephemeral KEM OID and key length	Reject a modified key, unsupported OID or invalid client certificate
KDC response	Signed KDCKEMInfo, ciphertext, nonce and KDF identifier	Reject any modified field before using the derived reply key
Key derivation	Selected KDF and a matching derived-key test vector	Fail closed on an unknown or mismatched KDF
Certificate path	Client and KDC chains, revocation policy and signature algorithms	Reject an untrusted, expired or policy-ineligible chain
Downgrade policy	Advertised capabilities, certificate class and chosen exchange	Do not silently replace a required PQ exchange with DH, ECDH or RSA
Transport	TCP connection, message sizes, timeouts and middlebox results	Expose a transport failure instead of retrying into a weaker mode

Acceptance checkpoints for an ML-KEM PKINIT trial.

Prove both protocol bindings

The client signature has to cover the AuthPack that carries the ephemeral encapsulation key. The KDC signature has to cover the KDCKEMInfo that carries the ciphertext and the selected key-derivation context. If either binding is missing, a successful ML-KEM operation does not prove an authenticated Kerberos exchange.

Flip one byte in the client's encapsulation key after signing. The KDC must reject the request before encapsulation.
Replace the KEM object identifier without changing the key bytes. The request must fail rather than reinterpret the key.
Flip one byte in the KDC ciphertext, nonce or KDF identifier. The client must reject the signed structure or fail key confirmation.
Replay a valid response against a different request. Nonce and transcript checks must prevent acceptance.
Supply a ciphertext with the wrong fixed length. The client must reject it before calling ML-KEM decapsulation.

Keep the malformed corpus under version control and record expected failure stages. A generic authentication error is not enough evidence if the implementation continued past certificate validation or attempted decapsulation on malformed input. This is where a focused post-quantum audit can separate protocol conformance from a green end-to-end login.

Test the certificate path separately from the KEM

ML-KEM protects key establishment, but it does not authenticate the client or KDC by itself. The draft states that post-quantum confidentiality requires both the KEM and the KDC signing algorithm to resist quantum attacks. An ML-KEM exchange authenticated with an RSA or ECDSA KDC certificate is not fully post-quantum authentication.

Build at least three certificate profiles: a conventional signing chain for transition tests, an ML-DSA chain using the standardized X.509 and CMS identifiers, and an intentionally invalid chain. For each, capture path building, name constraints, key usage, revocation behavior and trust-anchor selection. Do not report the KEM as production-ready until the required PKI can issue, distribute, validate, revoke and rotate the signing credentials.

Make downgrade behavior explicit

The draft distinguishes a post-quantum client credential from a traditional one. When a client uses a post-quantum signing certificate and offers a post-quantum KEM, it must not fall back to DH, ECDH or RSA. A traditional client credential may follow a different transition policy, but that policy must be configured and observable rather than inferred from a successful ticket.

Client credential	KEM offer	KDC capability	Expected result
Post-quantum	ML-KEM-768	ML-KEM supported	KEM path succeeds and records the negotiated identifiers
Post-quantum	ML-KEM-768	Classical only	Fail closed with no classical fallback
Traditional	ML-KEM-768	ML-KEM supported	Follow the approved transition policy and label authentication as traditional
Traditional	ML-KEM-768	Classical only	Allow or block only according to the documented cryptographic floor
Any	Unknown KEM OID	No match	Reject or negotiate another approved PQ KEM, never reinterpret silently

Minimum downgrade matrix. Adjust the allowed result to the organization's cryptographic floor.

Run the matrix with packet capture and structured logs. The acceptance artifact should show what was offered, what the KDC selected and why fallback was allowed or refused. Apply the same discipline used for a PQC rollback floor: policy becomes credible only when weaker negotiation is observable and testable.

Exercise the real TCP path

The proposal requires TCP for ML-KEM PKINIT. Its example combines a 1,184-byte ML-KEM-768 encapsulation key with a 3,309-byte ML-DSA-65 signature before the surrounding CMS and Kerberos structures are counted. The KDC response carries a 1,088-byte ML-KEM-768 ciphertext plus its signed wrapper. Those sizes make UDP success an unsafe test objective.

Confirm every client can reach every KDC over TCP port 88 through firewalls, load balancers and site links.
Measure request and response bytes at the application and packet layers.
Test connection setup, idle timeout, retransmission and concurrent-login bursts.
Inject TCP refusal, reset and delay. The client must surface an actionable error without weakening the exchange.
Repeat with certificate chains at expected rollover size, not only with the shortest lab chain.

Transport evidence belongs in the same release gate as cryptographic evidence. A KDC that verifies ML-KEM locally but cannot complete the signed exchange through the production path is not interoperable. Capacity results should feed the post-quantum migration service plan before any authentication dependency is moved.

Use a staged acceptance gate

Freeze the draft revision, algorithm OIDs, KDF set, certificate profiles and software builds.
Pass positive test vectors for key generation, encapsulation, decapsulation and reply-key derivation.
Pass the mutation corpus with failures at the expected validation stage.
Pass certificate-path and revocation tests for both client and KDC roles.
Pass the downgrade matrix with structured negotiation evidence.
Pass TCP reachability, failure injection and concurrency tests across every production path.
Document remaining draft dependencies and prohibit production use until the selected profile is standardized and supported.

What this test does not prove

The exercise does not make the current proposal an IETF standard, guarantee that its structures or identifiers will remain unchanged, or establish interoperability between independent Kerberos implementations. It also does not make a mixed classical-signature deployment fully post-quantum. Those limits should appear in the release record beside the passing results.

References

A useful PKINIT trial ends with reproducible failure evidence, not just a successful ticket. If the protocol binding, certificate path, downgrade floor or TCP route cannot be demonstrated independently, the migration gate remains open.

Where this goes next

Migration engineeringPlan and execute the move to post-quantum algorithms without breaking production.Plan a migration PQC readiness auditInventory your cryptography and rank the harvest-now-decrypt-later exposure.Book an audit Conformance certificationProve an ML-KEM / ML-DSA / SLH-DSA implementation actually follows the standard.Get certified