Summary

  • RFC 5349 allows a KDC that rejects a client's ECDH domain parameters to return TD-DH-PARAMETERS in decreasing KDC preference. The client may select one and retry, but the Kerberos error is not integrity protected. The returned order is negotiation input, not sufficient authority.
  • Client and KDC must maintain local policy for acceptable parameter sets when they lack prior knowledge. That policy can reject every offered choice or disable parameter negotiation. A successful retry proves an accepted intersection, not the authenticity of the error list.
  • When a long-term ECDH private key is used, failure to verify that a received public key is a valid point on the correct curve can leak information repeatedly until the private key is exposed. Certificate acceptance, point validation, shared-secret derivation, ticket issuance and application authorization require separate receipts.

The error changed the next action without earning trust

The flow looks authoritative. A client sends PA-PK-AS-REQ with an ECDH public value and domain parameters. The KDC rejects the choice with KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED, includes a TD-DH-PARAMETERS list, and orders the entries according to its own preference. The client can choose from the list and try again.

Yet the transport object carrying that advice has a decisive limitation: Kerberos error messages are not integrity protected in the mechanism described by RFC 5349. An attacker can alter the list so that the next choice is weaker or no longer mutually preferred.

The protocol therefore gives the message influence without giving it final decision rights. It can suggest candidates and order them. It cannot authorize the client to accept a curve that local policy forbids.

This distinction is easy to erase in an implementation. A negotiation routine receives a structured list from the server, chooses the first supported entry and retries. The code is interoperable, the second exchange succeeds, and the audit records only the final curve. None of those facts proves that the first list was authentic.

Local policy is the authority boundary

RFC 5349 requires both client and KDC to have local policy defining acceptable domain parameters when they do not already know the chosen set. Local policy may also prohibit negotiation of ECDH parameters altogether.

That requirement turns the retry into an intersection. The client has a locally approved set. The unauthenticated response supplies a claimed KDC set and preference order. Only values in the local set may survive to the next attempt.

An empty intersection is not a protocol inconvenience to be bypassed. It is the control outcome. Falling back to the first remotely offered curve would let an unauthenticated error rewrite the client's cryptographic policy.

The KDC needs the same discipline. Acceptance of a client proposal must follow its own local rules, not the mere fact that the encoding parses or that the curve is implemented by a library. Capability and permission remain different facts on both sides.

A successful retry does not authenticate the rejected list

Suppose an attacker removes the strongest mutually preferred entry but leaves another curve that the client's local policy allows. The client selects that surviving intersection, retries and completes PKINIT. The later cryptographic exchange can be valid even though the earlier recommendation was tampered with.

The result is not necessarily a protocol failure. Local policy did its job by preventing unacceptable parameters. But the successful retry cannot be used as retrospective evidence that the error list was authentic or that the KDC truly preferred the selected entry.

This creates two distinct audit questions. Was the final parameter permitted and correctly executed? Was the negotiation path faithful to the KDC's actual preference? The first can be green while the second remains unknown.

Telemetry that retains only the selected curve answers neither question completely. It should also record the original proposal, rejection code, received ordered list, local allow set, computed intersection, chosen retry value and whether negotiation was permitted at all.

A certificate is not the last mathematical check

RFC 5349 places ECC certificates and signatures inside the existing PKINIT and CMS structures. X.509 and CMS processing can establish that a certificate follows the expected profile and that signed material verifies under an accepted chain.

ECDH still needs another receipt. The recipient should verify that the sender's public key is a valid point on the correct elliptic curve. The certificate or message containing a bit string does not make every encoded point mathematically safe.

These checks answer different questions. Certificate-path validation concerns issuers, names, constraints, validity and signatures. Algorithm-identifier processing connects key and signature encodings to expected algorithms. Point validation determines whether the ECDH input lies on the intended group and satisfies the necessary properties.

Collapsing them into “certificate valid” makes it impossible to know whether the implementation actually enforced the curve boundary before using the private key.

Reuse turns one missing check into an iterative extraction surface

The risk becomes especially sharp when the recipient uses a long-term ECDH private key. RFC 5349 warns that accepting a public key that is not a valid point on the correct curve can leak information about that private key. Repeating the attack can eventually expose it completely.

The critical variable is not only algorithm choice. It is the combination of validation failure, key lifetime and the attacker's ability to submit repeated inputs and observe results.

A single successful authentication log does not show that invalid submissions were rejected. A key inventory does not show how many parse or calculation oracles reached the same long-lived secret. A certificate policy does not prove the library performed the exact point checks required before scalar multiplication.

For operations, every ECDH use should bind the input's source, curve identifier, validation result, private-key identity and lifetime, rejection reason, retry count and observable response. Rate limiting may reduce attempts, but it does not replace validation.

Key reuse is a permission carried by nonces, not an assumption

RFC 5349 preserves the RFC 4556 logic through which client and KDC can permit reuse of ECDH keys by including clientDHNonce and serverDHNonce. The mechanism is not a general statement that reuse is always acceptable.

Whether reuse occurred, which side allowed it, which key pair was reused and for how long all affect the security surface. A system that stores only the final shared key or ticket loses the condition that made reuse permissible.

The operational temptation is obvious: reuse can reduce computation and latency. But reuse also increases the number of adversarial inputs that may interact with one private value. The value of exact point validation rises with that exposure.

The ledger should connect reuse permission to the nonce fields, local policy, private-key instance, validation controls and retirement event. “ECDH completed” does not reveal any of them.

Smaller keys do not settle the operating model

RFC 5349 describes ECC as attractive because it can provide security comparable to then-popular RSA or DSA mechanisms with smaller keys. It includes an approximate equivalence table based on the cited historical NIST guidance and uses P-256 as an example for a 128-bit symmetric target.

That comparison is bounded. Key length does not by itself measure certificate lifecycle cost, hardware support, side-channel resistance, implementation quality, negotiation complexity, validation coverage or migration risk.

A smaller encoding may reduce some bandwidth, storage or computation. It can also introduce a new parser, new algorithm identifiers, new curve policy and new failure modes. Total operational cost requires evidence from the deployed system, not a conversion table alone.

The historical table should therefore be read as design context, not a current procurement scorecard. Current cryptographic policy needs current standards, platform behavior and threat assessment.

Mandatory support is an interoperability floor

RFC 5349 requires conforming implementations to support P-256 and P-384. That creates a common capability floor for the specification.

It does not prove that either curve is enabled in a particular deployment, appears in the client's proposal, survives local policy, is returned by the KDC, is selected in the retry, reaches shared-secret derivation or produces a ticket.

Similarly, required support for ecdsa-with-Sha256 describes implementation conformance to the historical document. It is not an observation that a particular certificate or signature used that algorithm.

Audits should separate implemented, configured, proposed, received, allowed, selected and executed. A standards checklist can establish only the first category unless runtime evidence supplies the rest.

Named curves trade configuration for concentration

The document distinguishes named curves, whose parameters are identified by an object identifier, from custom curves carrying explicit domain parameters. Named curves improve compactness and common understanding. RFC 4556 structures can represent both.

RFC 5349 describes less algebraic structure as a conservative principle, while acknowledging that special structure can improve efficiency. It also identifies a systemic concern: if one curve is used widely, a future attack on that curve could compromise many keys at once.

This does not make diversity automatically safe. More curves expand code paths, configuration, testing and downgrade surfaces. A widely used curve may receive better review and interoperability testing. The decision is a balance between concentration risk and operational complexity.

The appropriate evidence includes curve inventory, key count, implementation diversity, validation coverage, hardware dependencies, replacement time and observed negotiations. Counting supported names alone is not portfolio management.

Certificate parameters can remove one configuration and move its custody

ECDH can be used with any suitable certificates and signature schemes. When ECC certificates are used, their domain parameters can supply the exchange and remove the need for separately preconfigured parameters.

That is a useful simplification, but the authority does not vanish. It moves into certificate issuance, path validation, algorithm constraints, key parsing and local acceptance policy.

A certificate parameter is not self-authorizing because it arrived inside a certificate. The client and KDC still need to decide whether the certificate, algorithm and curve are permitted for this use.

Operational design should record which source supplied the parameters: explicit local configuration, current certificate, KDC error list or another mechanism. Without provenance, a reduced configuration footprint can look like reduced governance when governance merely changed location.

Shared-secret derivation is another bounded receipt

For an accepted ECDH exchange, both parties calculate an elliptic-curve point with the specified operation. The x-coordinate is converted into an octet string and used as DHSharedSecret in the RFC 4556 flow.

Successful derivation proves that the implementation produced the input required by the next PKINIT step. It does not itself validate the peer's organizational identity, issue a Kerberos ticket, acquire a service ticket, authorize an application action or show that the action completed.

Each stage can fail after the previous one succeeds. A valid curve and shared secret may still lead to an invalid signature or rejected AS reply. A valid ticket may still be denied by service policy. An authorized request may still fail in execution.

The evidence chain must keep these receipts separate instead of promoting cryptographic agreement into business authority.

Historical status bounds the claim

RFC 5349 was published in September 2008 as Informational. It makes no syntactic or semantic change to the RFC 4556 messages and does not specify an Internet Standard.

The captured RFC Editor errata search displayed no RFC 5349 records. That is a dated documentary observation, not proof that the text or every implementation is defect-free.

Later RFCs in the evidence packet update surrounding X.509 algorithm descriptions, ECC fundamentals, generalized Kerberos pre-authentication and Kerberos encryption guidance. They do not retroactively prove deployment of RFC 5349 or current safety of a named product.

The durable lesson is an authority pattern: an unauthenticated control message can legitimately influence retry behavior only when an independent policy constrains the result, and a validated container does not eliminate the need to validate the cryptographic object used inside it.