The Simple and Protected GSS-API Negotiation Mechanism
obsoleted by
- rfc-4178 — The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism
Extracted elements (24)
For odd-message-count mechanisms, there is an explicit design tradeoff between optimal message count and providing the initiator assurance against list modification. RFC 2478 leaves this choice to the implementation rather than mandating one approach.
The mechListMIC is introduced to protect the negotiation against active attackers who might modify the mechanism list in transit. When the selected mechanism supports integrity, the MIC over the original mechTypes list allows both peers to verify that no downgrade or substitution occurred.
To avoid an extra round trip during connection setup, the initiator may embed its preferred mechanism's initial security token in the NegTokenInit mechToken field. If the target selects the same preferred mechanism, no additional round trips are incurred by the negotiation protocol itself.
A GSS-API implementation that does not support the SPNEGO negotiation mechanism will return GSS_S_BAD_MECH upon receiving a negotiation token, behaving as if a specific but unsupported basic security mechanism had been requested. This provides defined failure semantics for mixed deployments.
The mechToken field in NegTokenInit is optional, and not all target implementations are required to support processing of a piggybacked initial mechToken. Targets that do support it can provide an optimistic response, but those that cannot may simply omit responseToken from the first reply.
For odd-message-count mechanisms, if the mechListMIC is present in the final NegTokenInit and is correct, GSS_S_COMPLETE is returned with no token. If it is present but invalid, context establishment MUST fail. If it is absent, GSS_S_COMPLETE MUST be returned to the target with a NegTokenTarg containing a MIC and no responseToken.
GSS_S_BAD_MECH MUST be returned by GSS_Init_sec_context() when the negotiation token carries a reject result, or when the target selects a mechanism not included in the initiator's original list.
GSS_S_BAD_MIC status is returned when the selected mechanism supports a MIC token but the MIC computed over the initiator's mechanism list is missing or incorrect.
If the mechanism selected by the negotiation does not support integrity, no mechListMIC is included. If it does support integrity, a mechListMIC MUST be used and validated as specified.
If the selected mechanism supports integrity and uses an even number of messages, the target MUST compute a mechListMIC (GetMIC over the MechTypes from NegTokenInit) and send it in the final NegTokenTarg. The initiator MUST require this field to be present and valid; absence of a valid mechListMIC means negotiation MUST fail.
In the absence of other policy, the target SHOULD choose the first mechanism in the initiator's list for which valid credentials are available.
The supportedMech field MUST be present in the NegTokenTarg when negResult is accept_completed or accept_incomplete, and it MUST be a mechanism chosen from those offered by the initiator.
When GSS_Acquire_cred is invoked with the negotiation mechanism as desired_mechs, an implementation-specific default credential is used and the set of mechanisms available for negotiation is as specified locally by the system administrator.
When the final negotiation token does not contain a MIC, the initiator MUST check that the returned/selected mechanism is on the originally submitted list and also verify that the selected mechanism is not capable of supporting a MIC.
GSS_Get_neg_mechs() is an additional API that returns the set of security mechanisms available for negotiation for a given credential handle, allowing callers to query what they may offer before initiating context establishment.
GSS_Set_neg_mechs() is an additional API that allows callers to restrict the set of security mechanisms available for negotiation on a given credential handle. The ordering of mechanisms in mech_set implies a relative preference for the target.
SPNEGO is a pseudo-security mechanism identified by OID iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2). It enables GSS-API peers to determine in-band whether they share common security mechanisms and, if so, to invoke normal context establishment for a selected mechanism.
Communicating peers are always exposed to denial-of-service threats regardless of whether integrity protection is in use, since an attacker can disrupt the negotiation exchange.
When the mechanism selected by the target supports integrity protection, the negotiation itself is protected against tampering. When any proposed mechanism does not support integrity, an active attacker can force selection of a weaker but mutually acceptable mechanism rather than the peers' common preferred one.
The negotiation proceeds: (a) initiator calls GSS_Init_sec_context emitting negTokenInit with GSS_S_CONTINUE_NEEDED; (b) target calls GSS_Accept_sec_context returning negTokenTarg with accept_completed, accept_incomplete, or reject; (c) initiator calls GSS_Init_sec_context with the target token, receiving GSS_S_COMPLETE, GSS_S_CONTINUE_NEEDED, or GSS_S_BAD_MECH. Subsequent tokens use the selected mechanism encapsulated in NegTokenTarg until both sides return GSS_S_COMPLETE.
ContextFlags is a BIT STRING with seven named bits: delegFlag(0), mutualFlag(1), replayFlag(2), sequenceFlag(3), anonFlag(4), confFlag(5), integFlag(6). These are filled from the req_flags parameter of GSS_Init_sec_context().
NegTokenInit is an ASN.1 SEQUENCE with four optional fields: mechTypes [0] (ordered MechTypeList of OIDs), reqFlags [1] (ContextFlags BIT STRING), mechToken [2] (OCTET STRING carrying the first mechanism's initial token), and mechListMIC [3] (OCTET STRING). The mechTypes field lists mechanisms in preference order.
NegTokenTarg is an ASN.1 SEQUENCE with: negResult [0] ENUMERATED (accept_completed=0, accept_incomplete=1, reject=2), supportedMech [1] MechType, responseToken [2] OCTET STRING, and mechListMIC [3] OCTET STRING. For subsequent tokens after the first, negResult and supportedMech are omitted.
The NegotiationToken is an ASN.1 CHOICE between negTokenInit (tag [0]) sent by the initiator and negTokenTarg (tag [1]) returned by the target. The innerContextToken field of the GSS-API InitialContextToken carries this structure, encoded in DER.