SPNEGO and GSSAPI

## The scheme is a pipe, not a credential format The HTTP `Negotiate` authentication scheme, described in **RFC 4559**, defines no credential of its own. It defines carriage. The service offers the scheme with a bare `WWW-Authenticate: Negotiate` header — no parameters and nothing for the client to fill in — and the client answers with `Authorization: Negotiate <base64>`, where the base64 is a **GSS-API context-establishment token** exactly as the security mechanism produced it. Base64 is present because the token is binary DER-encoded ASN.1 and a header field value is text. It provides no confidentiality at all: anyone who can read the header can decode the bytes. ## What the bytes decode to Two shapes appear in practice: - a **SPNEGO negotiation token** under mechanism OID `1.3.6.1.5.5.2` (RFC 4178) — a `NegTokenInit` whose `mechTypes` field lists the mechanisms the initiator supports in preference order, and whose optional `mechToken` optimistically carries the first of those mechanisms' own token; - a **bare Kerberos V5 GSS-API token** under OID `1.2.840.113554.1.2.2`, with no negotiation wrapper around it. When the selected mechanism is Kerberos, the innermost object is an `AP-REQ` (`[APPLICATION 14]`). It has two parts that behave very differently: 1. the **service ticket**, issued earlier by the realm's KDC and encrypted under the *service principal's* long-term key — the client carries it but cannot read it; 2. the **`Authenticator`** (`[APPLICATION 2]`), built fresh by the client and encrypted under the **session key** that arrived with the ticket, carrying `cname`, `ctime`/`cusec` and a checksum. The client's own long-term key — the value derived from the user's password by `string-to-key` — is not in the token and is not derivable from it. ## What the value is, and is not | The value is | The value is not | |---|---| | a handshake message for one context | a stored, reusable credential | | scoped to one named service principal | presentable at a second service | | binary ASN.1, base64 only for transport | protected by that base64 | | possibly one of several legs | guaranteed to finish in one request | ## The exchange, leg by leg 1. The client requests the resource with no credential. 2. The service answers `401` with `WWW-Authenticate: Negotiate` carrying no data. 3. The client obtains a service ticket for that service, builds the context token, and repeats the request with `Authorization: Negotiate <base64>`. 4. If the mechanism needs a further leg, the service answers `401` again, this time `WWW-Authenticate: Negotiate <base64>`, and the client feeds that token back into its own side of the exchange. 5. On success the service returns the resource, and **may** include a final `WWW-Authenticate: Negotiate <base64>` on the `200` response. That last header is the part most readers skip past. When the initiator asked for mutual authentication — `GSS_C_MUTUAL_FLAG (2)` in the Kerberos mechanism's request — the acceptor's final token is what lets the client conclude that the service genuinely held the key the ticket was sealed under. A client that discards it has proved the user to the service and learned nothing about the service. ## Why the extra round trip exists The first request in the flow is deliberately credential-free, so every new context costs an extra request and response. Two things reduce that cost in practice: a client that remembers a host answered with `Negotiate` may send the token on the first request next time, and a context established on a persistent connection can serve later requests on it. Neither changes the shape of the exchange; they change how often you pay for it. ## Where this goes wrong - **Reading base64 as protection.** It is an encoding. The token's security comes from the sealed ticket and the keyed `Authenticator` inside it, not from the wrapper. - **Treating the blob as portable.** The ticket names one service principal and is encrypted under that principal's key; another service holds a different key and cannot open it. - **Expecting a readable document.** There is no JSON and no claim set here; the payload is ASN.1 that only the mechanism parses. - **Ignoring the final token.** Dropping the `200` response's header quietly turns a mutually authenticated exchange into a one-directional one. - **Assuming one leg.** Some mechanisms and some negotiations need two or three, and the intermediate legs look exactly like authentication failures to a reader who only counts `401`s.