What does GSS-API give a client application, and why is SPNEGO called a pseudo-mechanism inside it?

middlemust knowfreq 46%

answer

an API contract, not a wire protocol
one loop, opaque tokens relayed
mechanisms identified by object identifier
the negotiator proves nobody's identity
flags ride in the 0x8003 checksum

basics

~10 s

GSS-API gives one mechanism-independent loop: GSS_Init_sec_context and GSS_Accept_sec_context exchange opaque tokens until a context exists. SPNEGO is a mechanism whose only work is choosing which real mechanism, named by OID, both ends will run.

solid answer

~40 s

GSS-API (RFC 2743) is an API, not a wire protocol. The initiator calls GSS_Init_sec_context and the acceptor GSS_Accept_sec_context; each call returns an opaque token the application relays to the peer without parsing it, and the loop continues while the status is GSS_S_CONTINUE_NEEDED and stops at GSS_S_COMPLETE. After that the application may call GSS_GetMIC for integrity or GSS_Wrap for integrity with optional confidentiality. Which security protocol actually runs is selected by mechanism OID — Kerberos V5 is 1.2.840.113554.1.2.2. SPNEGO (OID 1.3.6.1.5.5.2, RFC 4178) plugs into the same API, but its tokens carry a list of mechanism OIDs and then the selected mechanism's tokens rather than any authentication material of its own. It negotiates; it does not authenticate.

GSS-API (RFC 2743) is an API, not a wire protocol. The initiator calls `GSS_Init_sec_context` and the acceptor `GSS_Accept_sec_context`; each call returns an opaque token the application relays to the peer without parsing it, and the loop continues while the status is `GSS_S_CONTINUE_NEEDED` and stops at `GSS_S_COMPLETE`. After that the application may call `GSS_GetMIC` for integrity or `GSS_Wrap` for integrity with optional confidentiality. Which security protocol actually runs is selected by mechanism OID — Kerberos V5 is `1.2.840.113554.1.2.2`. SPNEGO (OID `1.3.6.1.5.5.2`, RFC 4178) plugs into the same API, but its tokens carry a list of mechanism OIDs and then the selected mechanism's tokens rather than any authentication material of its own. It negotiates; it does not authenticate.

code

pseudocode · 21 lines

pseudocode

token = empty

loop
    status, token = GSS_Init_sec_context(
        target    = "HTTP/archive.internal.example",
        mechanism = SPNEGO,
        flags     = GSS_C_MUTUAL_FLAG,
        input     = token)

    if token is not empty
        send base64(token) to the acceptor

    if status is GSS_S_COMPLETE
        break

    # status was GSS_S_CONTINUE_NEEDED
    token = receive token from the acceptor
end loop

# context established; per-message calls become available
protected = GSS_GetMIC(context, application_data)

go deeper

for a junior

Remember the division of labour: the application only relays opaque tokens, and something underneath decides how identity is actually proved.

for a middle

Explain the init and accept loop, what the continue and complete statuses mean, and why a negotiating mechanism can occupy the mechanism slot without proving anyone's identity.

for a senior

Be able to say where requested context flags actually live for the Kerberos mechanism, and to reason about what a negotiation adds to the exchange besides a wrapper.

for a principal

Judge whether mechanism independence is worth its cost in your estate: it buys one code path across protocols, and it introduces a choice an adversary in the path would like to steer.

An API that deliberately hides the protocol

GSS-API, the Generic Security Service API of RFC 2743, exists so that an application can authenticate a peer without containing any authentication code. The application's entire obligation is to move opaque octet strings between itself and the peer. It never parses them, never inspects them, and is not told what is inside. Swap the mechanism underneath and the application source does not change — that is the whole bargain.

The two calls that matter for establishing a context are:

GSS_Init_sec_context, called by the initiator, which names a target and returns a token to send;
GSS_Accept_sec_context, called by the acceptor, which consumes a token and may return one to send back.

Each returns a status. GSS_S_CONTINUE_NEEDED means relay this token and expect another; GSS_S_COMPLETE means the context exists. Once a context exists, two more calls make it useful:

GSS_GetMIC produces a message integrity code over application data, leaving that data in the clear;
GSS_Wrap produces a protected message with integrity and, if asked, confidentiality.

Over HTTP Negotiate the per-message calls are usually unused — the context is established to prove identity and then set aside — but the negotiation layer itself uses GSS_GetMIC, which matters later.

Mechanisms are named by OID

A GSS-API mechanism is identified by an object identifier, and the OID is part of the token on the wire, not merely a local setting:

OID	What it names
`1.2.840.113554.1.2.2`	the Kerberos V5 mechanism (RFC 4121, revising RFC 1964)
`1.3.6.1.5.5.2`	SPNEGO, the negotiation pseudo-mechanism (RFC 4178)

An OID is an identity, not a version number. A newer revision of the Kerberos mechanism's token framing kept the same OID precisely because the mechanism is the same mechanism.

Why SPNEGO is a mechanism that authenticates nobody

SPNEGO satisfies the GSS-API mechanism interface — you can select it, initialise it, and loop on it exactly like any other — but its tokens carry:

a list of mechanism OIDs the initiator is willing to use, most preferred first;
optionally, an optimistic token already produced by the first of those mechanisms;
the selected mechanism's tokens, once a choice has been made;
a checksum over the advertised list, exchanged after the fact.

Nothing in that set proves who anyone is. SPNEGO's contribution is the choice, and then transparent relaying. That is why it is described as a pseudo-mechanism: it occupies the mechanism slot so that the application keeps one code path even when the estate runs more than one authentication protocol, and so that the strongest mechanism both ends support can be found without the application knowing the list.

What the Kerberos mechanism puts into its token

When SPNEGO selects Kerberos, the mechanism's context request travels in a place worth knowing. The requested context flags are encoded in the checksum field of the Authenticator inside the AP-REQ, using checksum type 0x8003 defined by the mechanism. Its flag field carries, among others:

GSS_C_DELEG_FLAG (1) — the initiator asks for its credential to be forwarded;
GSS_C_MUTUAL_FLAG (2) — the initiator asks the acceptor to prove itself in return;
GSS_C_SEQUENCE_FLAG (8) — the initiator asks for sequencing of later per-message tokens.

The delegation fields (DlgOpt, Dlgth, Deleg) appear in that checksum only when the delegation flag is set; otherwise the structure simply ends earlier. A reader who expects flags to sit in a header field of their own will not find them.

The consequences worth carrying away

The application is not a participant in the protocol. It is a courier. If you are debugging and find application code that inspects the token, that code has broken the abstraction and will break again when the mechanism changes.
The number of legs is a property of the mechanism, not of the API. One leg, two or three are all normal, and the loop is written for the general case.
Selection is visible on the wire. The mechanism OID is inside the token, so an exchange can be classified without guessing.
SPNEGO's presence costs something. It adds a wrapper, and it adds a decision that an attacker in the path would like to influence — which is why the negotiation carries its own integrity check.

## An API that deliberately hides the protocol **GSS-API**, the Generic Security Service API of RFC 2743, exists so that an application can authenticate a peer without containing any authentication code. The application's entire obligation is to move opaque octet strings between itself and the peer. It never parses them, never inspects them, and is not told what is inside. Swap the mechanism underneath and the application source does not change — that is the whole bargain. The two calls that matter for establishing a context are: - **`GSS_Init_sec_context`**, called by the initiator, which names a target and returns a token to send; - **`GSS_Accept_sec_context`**, called by the acceptor, which consumes a token and may return one to send back. Each returns a status. `GSS_S_CONTINUE_NEEDED` means *relay this token and expect another*; `GSS_S_COMPLETE` means *the context exists*. Once a context exists, two more calls make it useful: - **`GSS_GetMIC`** produces a message integrity code over application data, leaving that data in the clear; - **`GSS_Wrap`** produces a protected message with integrity and, if asked, confidentiality. Over HTTP `Negotiate` the per-message calls are usually unused — the context is established to prove identity and then set aside — but the negotiation layer itself uses `GSS_GetMIC`, which matters later. ## Mechanisms are named by OID A GSS-API mechanism is identified by an object identifier, and the OID is part of the token on the wire, not merely a local setting: | OID | What it names | |---|---| | `1.2.840.113554.1.2.2` | the Kerberos V5 mechanism (RFC 4121, revising RFC 1964) | | `1.3.6.1.5.5.2` | SPNEGO, the negotiation pseudo-mechanism (RFC 4178) | An OID is an identity, not a version number. A newer revision of the Kerberos mechanism's token framing kept the same OID precisely because the mechanism is the same mechanism. ## Why SPNEGO is a mechanism that authenticates nobody SPNEGO satisfies the GSS-API mechanism interface — you can select it, initialise it, and loop on it exactly like any other — but its tokens carry: - a **list** of mechanism OIDs the initiator is willing to use, most preferred first; - optionally, an **optimistic token** already produced by the first of those mechanisms; - the **selected mechanism's** tokens, once a choice has been made; - a **checksum over the advertised list**, exchanged after the fact. Nothing in that set proves who anyone is. SPNEGO's contribution is the choice, and then transparent relaying. That is why it is described as a pseudo-mechanism: it occupies the mechanism slot so that the application keeps one code path even when the estate runs more than one authentication protocol, and so that the strongest mechanism both ends support can be found without the application knowing the list. ## What the Kerberos mechanism puts into its token When SPNEGO selects Kerberos, the mechanism's context request travels in a place worth knowing. The requested context flags are encoded in the checksum field of the `Authenticator` inside the `AP-REQ`, using **checksum type `0x8003`** defined by the mechanism. Its flag field carries, among others: - `GSS_C_DELEG_FLAG (1)` — the initiator asks for its credential to be forwarded; - `GSS_C_MUTUAL_FLAG (2)` — the initiator asks the acceptor to prove itself in return; - `GSS_C_SEQUENCE_FLAG (8)` — the initiator asks for sequencing of later per-message tokens. The delegation fields (`DlgOpt`, `Dlgth`, `Deleg`) appear in that checksum **only** when the delegation flag is set; otherwise the structure simply ends earlier. A reader who expects flags to sit in a header field of their own will not find them. ## The consequences worth carrying away 1. **The application is not a participant in the protocol.** It is a courier. If you are debugging and find application code that inspects the token, that code has broken the abstraction and will break again when the mechanism changes. 2. **The number of legs is a property of the mechanism, not of the API.** One leg, two or three are all normal, and the loop is written for the general case. 3. **Selection is visible on the wire.** The mechanism OID is inside the token, so an exchange can be classified without guessing. 4. **SPNEGO's presence costs something.** It adds a wrapper, and it adds a decision that an attacker in the path would like to influence — which is why the negotiation carries its own integrity check.

What may an application do with the context once the loop completes?
Call `GSS_GetMIC` to attach integrity to a message it sends in the clear, or `GSS_Wrap` for integrity with optional confidentiality. Over HTTP `Negotiate` these are usually unused, because the context is established to establish identity and the transport already protects the body; the negotiation layer, however, uses `GSS_GetMIC` for its own checksum over the mechanism list.
How does the Kerberos mechanism communicate the flags the initiator requested?
In the checksum field of the `Authenticator` inside the `AP-REQ`, using checksum type `0x8003`. Its flag field carries `GSS_C_DELEG_FLAG (1)`, `GSS_C_MUTUAL_FLAG (2)` and `GSS_C_SEQUENCE_FLAG (8)` among others, and the delegation fields `DlgOpt`, `Dlgth` and `Deleg` follow only when the delegation flag is set.
Why must the application never parse the token it relays?
Because mechanism independence is the point. The token's structure belongs to whichever mechanism was selected, and that choice can change per peer and per deployment. An application that reads the bytes has bound itself to one mechanism's format and will break the next time the negotiation lands somewhere else.

Two clerks relay sealed pouches between their own back offices, forbidden to open any of them. The first pouch does not argue a case; it only says which back office should handle all the rest.

saying these in an interview costs you the question

Thinks GSS-API is a wire protocol rather than an API
Says SPNEGO authenticates the user by itself
Assumes one round trip always establishes a context
Treats the mechanism OID as a version number
Believes the application must decode tokens to route them

What does GSS-API give a client application, and why is SPNEGO called a pseudo-mechanism inside it?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

An API that deliberately hides the protocol

Mechanisms are named by OID

Why SPNEGO is a mechanism that authenticates nobody

What the Kerberos mechanism puts into its token

The consequences worth carrying away

▾common follow-ups3 questions

▾analogy~20 s

▾red flags5 flags

An API that deliberately hides the protocol

Mechanisms are named by OID

Why SPNEGO is a mechanism that authenticates nobody

What the Kerberos mechanism puts into its token

The consequences worth carrying away

answer

go deeper