Summary

  • In the exchanges that contain a response token, RFC 2025 builds the context ID from the initiator’s randSrc followed by the target’s randTarg. That two-part value lets each side recognise that the other took part in separating the new context from old ones.
  • Unilateral SPKM-2 has only an SPKM-REQ. The target contributes no random value, so it must accept the initiator’s freshness claim or reject the context. key-src-bind strengthens the binding of that request and proposed key; it does not manufacture a target contribution.
  • Establishment replay protection and the optional replay or sequencing services used for later protected messages are separate decisions. A context ID is not evidence of authorisation, delivery, or business completion.

A receipt whose authors can be counted

RFC 2025 specifies the Simple Public-Key GSS-API Mechanism, or SPKM. Its context-establishment tokens carry many fields, but one small construction gives the exchange an unusually clear evidentiary shape. The initiator supplies randSrc. If a target response follows, the target appends randTarg. Their concatenation becomes the context ID used in subsequent tokens for that security context.

That ordering matters. The identifier is not merely a label assigned after the event; its components reveal which peer contributed to freshness. With both values present, the initiator knows that the target generated something for this exchange, while the target knows that its own contribution is included alongside the initiator’s. The resulting value is therefore a narrow bilateral receipt: it distinguishes this context-establishment conversation from an old one with high probability.

The word narrow is essential. RFC 2025 says the random values need not be unpredictable. They need to be generated so that a previously used value is very unlikely to recur. Their job here is uniqueness across contexts, not secrecy. A strong random-looking value cannot enlarge the claim beyond that job.

Four exchanges, one decisive asymmetry

The protocol’s token patterns expose the difference. SPKM-1 always uses a target response. In its unilateral form the exchange is SPKM-REQ followed by SPKM-REP-TI; in mutual authentication it adds SPKM-REP-IT. Mutual SPKM-2 also includes a response. In all of those cases, a target-generated random value can join the initiator’s value in the context ID.

Unilateral SPKM-2 is the exception. It consists only of SPKM-REQ. There is no reply token in which the target can contribute randTarg. The context ID is therefore the initiator’s value alone. RFC 2025 states the consequence directly: the target must trust the initiator to provide a fresh random value, or reject the context.

This is not a cosmetic difference between a one-token and a two-token handshake. It relocates control over freshness. In the responding exchanges, each peer places its own non-reuse contribution inside the identifier. In unilateral SPKM-2, the party deciding whether to accept the context has no such contribution. The identifier can still be useful, but it is not evidence that both sides participated in making the context fresh.

What key-src-bind repairs—and what it leaves open

RFC 2025 adds another protection to unilateral SPKM-2. When the chosen key-establishment algorithm does not itself bind the source name to the context key, the request must carry key-src-bind, computed as an MD5 digest over the encoded source name and the proposed context key.

This binding helps the target decide that the received token and key belong together with the claimed source. The RFC describes it as assisting the target in trusting the freshness of the token and proposed key. But the field is still produced inside the initiator’s request. It does not add a response, does not add randTarg, and does not show that the target generated fresh material.

The distinction is easy to lose in a database column called “context established” or a diagram that collapses the entire exchange to one green arrow. Binding, freshness contribution and mutual authentication are different facts. A control that strengthens one of them must not be counted as evidence for the others.

Two replay planes

SPKM also supports replay detection and sequencing for protected messages sent after establishment. Those services use sequence numbers when the application requests them. They are not automatically implied by the random values that separate one context from another.

The generic GSS-API specification, RFC 2743, keeps the distinction explicit. Replay and sequence services are selectable context flags for per-message processing. A caller asks for them, the acceptor reports what was available, and an implementation may still return a suspect message with supplementary status information. Meanwhile, the application remains responsible for transporting context-establishment and per-message tokens.

So there are two different questions for an audit trail:

  1. Was this context-establishment attempt distinguished from old context attempts?
  2. Were later messages checked for duplication or order within the accepted context?

A context ID helps answer the first. Negotiated flags, sequence state and per-message verification results answer the second. Combining them creates a claim the protocol never made.

The historical record, kept to scale

The RFC Editor records RFC 2025 as an October 1996 Proposed Standard, with no published erratum listed for the document at the time of this review. IANA’s SMI registry still records object identifiers for SPKM-1, SPKM-2, SPKM-3 and the SPKM GSS token arc. Those records establish specification history and identifier allocation; they do not show contemporary deployment.

RFC 2847 later defined SPKM-3 as equivalent to SPKM-1 except for specified changes. That relationship is useful for tracing the mechanism family, but it does not alter the evidence boundary in RFC 2025: one can read the context ID only in light of the exchange that produced it.

The safe interpretation is therefore compact. A two-part randSrc || randTarg context ID records bilateral freshness contribution for the security context. A unilateral SPKM-2 context ID records only the initiator’s contribution, even when key-src-bind is present. Neither form proves certificate authorisation, algorithm choice, later message delivery, or a successful business outcome.

Sources