The Simple Public-Key GSS-API Mechanism (SPKM)
Extracted elements (30)
An 8-byte random confounder is prepended to data before encryption (as in Kerberos) to compensate for the use of an IV of zero. Without the confounder, the strength of integrity mechanisms like md5-DES-CBC would be at most equal to DES under known-plaintext attack.
Both peers contribute random numbers to the context-id to assure each of freshness and preclude replay attacks where a token from an old context is injected into a new one. SPKM-2 unilateral auth cannot provide this assurance to the target.
CertificationPath separates userKeyId/userCertif from verifKeyId/userVerifCertif to allow different key pairs for encryption/decryption versus signing/verification. Presence of verification fields [2] or [3] implies encryption fields [0] or [1] must also be present.
SPKM is split into two mechanisms: SPKM-1 uses random numbers for replay detection during context establishment (usable without secure timestamps), while SPKM-2 uses timestamps. This allows deployment in environments where secure time is not available.
The MAC option for the Integrity field is provided to reduce processing overhead for anonymity cases (where the initiator signs the second token but MACs the first) and for re-establishing cached contexts (where all tokens are MACed).
SPKM data formats and procedures are designed to be as similar to the Kerberos V5 GSS-API mechanism as practical, to ease implementation in environments where Kerberos is already deployed. SPKM can serve as a drop-in replacement for any application using GSS-API.
All innerContextTokens are encoded using ASN.1 BER constrained to the DER subset defined in X.509 clause 8.7, in the interest of parsing simplicity.
All SPKM tokens, including SPKM-REP-TI, SPKM-REP-IT, SPKM-ERROR, context-deletion, and per-message tokens, shall be enclosed within the GSS-API InitialContextToken framing defined in RFC-1508 Appendix B.
DES-MAC is RECOMMENDED for integrity and DES-CBC is RECOMMENDED for confidentiality. These are not mandatory to preserve exportability of implementations.
For SPKM-2 unilateral authentication (no response token expected), the initiator MUST set exactly one bit in the pvno field since no protocol negotiation can take place.
MD5 is the MANDATORY one-way function (O-ALG) for subkey derivation. It is used in the formula: rightmost_k_bits(OWF(context_key || x || n || s || context_key)).
RSAEncryption (PKCS1) is the MANDATORY key establishment algorithm (K-ALG). The context key is generated by the initiator, encrypted with the target's RSA public key, and sent to the target.
The key-src-bind field in SPKM-REQ MUST be present for SPKM-2 unilateral authentication when the K-ALG in use does not bind the source name to the symmetric key. It holds MD5(src || context_key).
The md5WithRSAEncryption algorithm is MANDATORY for integrity. For interoperability, it must also be the algorithm used to sign all context establishment tokens that are signed rather than MACed.
The set of integrity AlgIDs sent by the initiator MUST contain at least one non-repudiable digital signature algorithm and at least one repudiable integrity algorithm; the target's returned subset must also satisfy this requirement.
Context-id is computed by concatenating the initiator's fresh random number with the target's fresh random number (for multi-pass exchanges). For SPKM-2 unilateral auth, only the initiator's random number forms the context-id.
SPKM_Parse_token() is a mandatory support function that parses mech_type, token_type, and context_handle from any SPKM token without performing cryptographic processing, enabling applications with multiple simultaneous contexts to route tokens correctly.
SPKMInnerContextToken is a CHOICE of seven token types: req [0] SPKM-REQ, rep-ti [1] SPKM-REP-TI, rep-it [2] SPKM-REP-IT, error [3] SPKM-ERROR, mic [4] SPKM-MIC, wrap [5] SPKM-WRAP, and del [6] SPKM-DEL.
The QOP parameter is a 32-bit unsigned integer divided into a confidentiality half (bits 31-16) and an integrity half (bits 15-0), each subdivided into TS (5 bits), U (3 bits), IA (4 bits), and MA (4 bits) fields.
The subkey derivation algorithm computes: rightmost_k_bits(OWF(context_key || x || n || s || context_key)), where x is 'C' (0x43) for confidentiality or 'I' (0x49) for integrity subkeys, n is the algorithm index, and s is the processing stage.
Checksums are computed over user data logically prepended by the plaintext token header (mic-header or wrap-header), binding data to the entire header to minimize the possibility of malicious splicing of checksums across messages.
RSA modulus bitlength discrepancies during context establishment can be resolved using SPKM-ERROR: the initiator signs with its strongest supported RSA; if the target cannot verify it, the target sends SPKM-ERROR signed with its strongest RSA, allowing iterative negotiation.
Sequence numbers are used purely for security (not reliability): to detect malicious loss, replay, or reordering of tokens. The direction indicator in SeqNum detects maliciously reflected tokens. Applications should request both sequencing and replay detection.
SPKM-1 mutual authentication: initiator sends SPKM-REQ, target responds with SPKM-REP-TI, initiator completes with SPKM-REP-IT. SPKM-2 mutual auth terminates after REP-TI. SPKM-2 unilateral uses only SPKM-REQ; SPKM-1 unilateral uses REQ and REP-TI.
Rep-ti-contents tok-id shall contain 0x0200; Rep-it-contents tok-id shall contain 0x0300; ERROR-TOKEN tok-id shall contain 0x0400. These tok-id values cryptographically bind data to the intended token type.
Req-contents includes tok-id INTEGER = 0x0100, context-id Random-Integer, pvno BIT STRING, optional UTCTime timestamp (mandatory for SPKM-2), randSrc, targ-name, optional src-name, req-data Context-Data, and key establishment fields.
SeqNum consists of num INTEGER (the 4-byte sequence number) and dir-ind BOOLEAN (FALSE when sender is context initiator, TRUE when sender is context acceptor), providing both sequencing and reflection attack detection.
SPKM-DEL Del-Header tok-id shall contain 0x0301. The int-cksum is computed as for gss_getMIC() except the user-data component is a zero-length string.
SPKM-MIC consists of Mic-Header (tok-id=0x0101, context-id, optional int-alg AlgorithmIdentifier, optional snd-seq SeqNum) followed by int-cksum BIT STRING covering header and data.
SPKM-WRAP consists of Wrap-Header (tok-id=0x0201, context-id, optional int-alg, optional conf-alg, optional snd-seq) and Wrap-Body (int-cksum BIT STRING, data BIT STRING containing plaintext or encrypted data).