Summary

  • RFC 5349 extends PKINIT with ECC certificates, ECC signatures and ECDH without changing the syntax or semantics of the RFC 4556 messages. When a KDC rejects the client's curve parameters, it can return KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED with a preference-ordered TD-DH-PARAMETERS list for a retry.
  • That list is not integrity protected. RFC 5349 therefore requires both client and KDC to maintain local policy for acceptable domain parameters. The intersection of local policies can authorize a retry; the received preference list cannot rewrite either policy.
  • Curve recognition, certificate validation, public-point validation, shared-secret derivation, KDC reply authentication, ticket issuance, service authorization and the user's intended login are different receipts. A dashboard that keeps only “PKINIT succeeded” cannot reconstruct which curve was offered, who allowed it or whether a long-term key was exposed to a hostile point.

Error 65 carried information, not authority

PKINIT allows a Kerberos client to use public-key cryptography during initial authentication. RFC 5349 adds the ECC mechanics. A client choosing ECDH places its public value and domain parameters in clientPublicValue inside PA-PK-AS-REQ. The KDC examines the proposal against its own policy.

If the KDC does not accept the parameters, it returns Kerberos error 65, KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The associated typed data contains a sequence of acceptable parameter sets, ordered from the KDC's most to least preferred. The client can choose one and retry.

That is a useful interoperability mechanism. It is also an obvious place to confuse a remote hint with a local decision. The error tells the client what the apparent peer says it supports. It does not prove that the message reached the client unchanged, and it does not grant permission to use every item in the list.

RFC 5349 says why directly: Kerberos error messages are not integrity protected. An attacker can change the list so that the client selects parameters that are weaker or not mutually preferred. The protocol's response is not to pretend that the error is authenticated. It requires both endpoints to possess local policy defining what they will accept when they lack prior knowledge.

The right model is an intersection, not a download. A client may retry only with a parameter set allowed by its own policy and plausibly supported by the KDC. The KDC then applies its policy again. The wire list narrows discovery; it does not enlarge authority.

Preference order is a claim about the peer

The list has an order. That order can help two implementations converge without trying every possible curve. But “first” means “the KDC's claimed preference,” not “the strongest universally available choice” and not “the organization's approved baseline.”

Those categories can diverge for legitimate reasons. A KDC may prioritize interoperability with an installed population. A client fleet may have a newer policy. A hardware token may support only a subset. A regulated workload may prohibit an option still permitted elsewhere. A curve identifier can be technically understood by both parties while remaining locally forbidden for this account, device or assurance tier.

An unauthenticated preference list is therefore evidence that belongs in a negotiation log. It is not configuration input to be copied blindly into an allow-list. If software silently persists a newly observed curve after a successful retry, a transient network message becomes durable security policy without a principal authorizing the change.

The durable record should retain the original offer, the exact error and typed-data bytes, the retry selection, the local-policy rule that admitted it, and the result of the second request. Without those fields, an operator can see that authentication eventually succeeded but cannot distinguish normal convergence from downgrade pressure.

A named curve did not validate the point

Even after client and KDC agree on domain parameters, the received public value remains a separate object. RFC 5349 tells the recipient to perform the public-key checks described by IEEE P1363. The warning becomes especially strong when the recipient uses a long-term ECDH private key: verify that the sender's public key is a valid point on the correct curve, or repeated interactions can leak information about the private key and eventually expose it.

This separates two facts that operational systems often collapse. The algorithm identifier can name a recognized curve. The encoded point can still fail membership or validity checks. “P-256 selected” does not mean “peer public key valid.”

The difference is sharper when state survives sessions. An ephemeral key limits how much one malformed interaction can expose. A long-term private key gives an attacker repeated observations against the same secret. The risk is cumulative, so the audit record must bind the validation result to the key instance and reuse state, not merely to the protocol version.

NIST SP 800-56A Rev. 3 provides a current captured reference for elliptic-curve key-establishment validation. NIST has announced an update to that publication, not its withdrawal. SP 800-186 and FIPS 186-5 supply current captured curve and signature context. Those later documents should guide current cryptographic policy; they do not retroactively turn RFC 5349's 2008 list into a complete 2026 baseline.

A computed secret was not yet a login

When the parameters and public values are accepted, client and KDC calculate an elliptic-curve shared point. RFC 5349 maps its x-coordinate to an octet string and uses that value as the DHSharedSecret, after which the parties continue under PKINIT and Kerberos.

That computation is important, but it is not the final operational result. A shared value does not by itself prove that the certificate path was authorized for the asserted client, that the key purpose was acceptable, that the request was fresh, that the authenticated KDC was the intended administrative realm, that a ticket was issued, that a service accepted it, or that the person reached the intended session.

The evidence chain therefore needs distinct receipts:

  1. the offered parameters and public value;
  2. local-policy evaluation on both sides;
  3. certificate and key-purpose validation;
  4. received-point validation;
  5. ECDH secret derivation and key-reuse state;
  6. the selected key-derivation behavior;
  7. authenticated KDC reply and ticket issuance;
  8. service authorization; and
  9. the user-visible outcome.

A single “pre-authentication passed” field is too compressed to answer an incident question at any of those boundaries.

Certificate-carried parameters remove configuration, not judgment

RFC 5349 notes an operational advantage of using ECDH with ECC certificates: the domain parameters in the client or KDC certificate can be reused, removing the need to preconfigure them separately.

That is a reduction in configuration surfaces. It is not an abolition of policy. The certificate still needs a valid path, appropriate use, current status and a binding to the intended principal. The parameter set still needs to satisfy local requirements. The received ECDH point still needs validation. A certificate can carry a curve without authorizing every service to use it.

The distinction matters because automation rewards fewer knobs. Teams can mistake “no extra local parameter file required” for “no local decision required.” RFC 5349 says the opposite when there is no prior knowledge: local policy is mandatory. The certificate may provide the candidate; the endpoint remains responsible for acceptance.

Interoperability creates concentration as well as compatibility

RFC 5349 requires P-256 and P-384 support for conforming implementations. It also discusses named and custom curves, the attraction of conservative structures, and the concern that universal reliance on one curve could turn a future break into a broad failure. The document does not claim that such a break occurred. It frames a governance trade-off.

Common named curves reduce ambiguity, implementation cost and failed negotiation. Diversity can limit common-mode exposure but increases test burden, parser surface and interoperability risk. Custom curves can preserve choice while creating more ways to disagree about parameters and validation.

The right leadership question is not “standardization or diversity?” in the abstract. It is which options are required for a defined interoperability population, which are permitted locally, how exceptions expire, and how the organization will identify every key and service affected by a policy change.

RFC 8636 later adds PKINIT algorithm agility and retains the same underlying logic. If negotiated KDF information is absent, the client may be facing an older KDC or a downgrade; local policy decides whether compatibility justifies continuation. The durable principle is that compatibility evidence can inform a bounded endpoint decision but cannot manufacture authorization.

The standard is historical evidence, not a current deployment census

RFC 5349 is Informational. It describes a protocol use, not a measured account of current Kerberos estates. The captured IANA registry confirms assigned Kerberos numbers; it does not show which implementations enable ECC PKINIT or which curves they accept.

The 2026 PKINIT post-quantum draft demonstrates that parameter discovery and retry remain active design questions, but it is a work in progress. Its proposed mechanics must not be reported as deployed standard behavior. NIST's announced SP 800-56A update is likewise a monitoring event, not evidence that the captured revision has ceased to apply.

Lu Heng's Minimum Initial Specification lens is useful only as a later analogy. A shared protocol can define the minimum interoperable grammar while leaving future acceptance decisions with the participant running the code. His Reality Layers lens adds a second discipline: the symbolic curve identifier, the documentary preference, the cryptographic validation and the operational login outcome must not be presented as one fact. Neither note caused or endorsed RFC 5349.