LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM
Extracted elements (30)
A new SPKM-3 mechanism type was created rather than modifying SPKM-1 because the semantic changes needed for the low-infrastructure model (no initiator certificate, dhKeyAgreement required, different algorithm mandates) stretched RFC 2025 interpretation to the point where backward compatibility would be endangered.
cast5CBC was chosen as the mandatory SPKM-3 confidentiality algorithm over DES EDE3 (too slow: ~1.6 MB/s vs ~7.1 MB/s) and RC4 (intellectual property issues) because it offers royalty-free licensing, reasonable performance, and the cast6CBC superset was evaluated by NIST as having a 'high security margin' with no major security gaps.
HMAC-MD5 rather than HMAC-SHA1 was chosen as the mandatory MAC for SPKM-3 because SHA-1 is approximately half the speed of MD5, and a MAC based on an encryption algorithm like cast5CBC was not selected because MD5 is 31% faster than the fastest such encryption algorithm.
md5WithRSAEncryption is demoted from REQUIRED (as in SPKM-1) to RECOMMENDED in SPKM-3 due to RSA intellectual property considerations, though it is still strongly recommended given the proliferation of RSA-keyed certificates in existing PKI deployments.
Adding cast5CBC, id-dsa-with-sha1, HMAC-MD5, and sha1WithRSAEncryption MA algorithm values to SPKM-1 and SPKM-2 does not impair backward compatibility because SPKM negotiates algorithms; an older SPKM-1/SPKM-2 peer that does not recognize these MA values will simply not select them.
When the LIPKEY caller sets anon_req_flag=TRUE, LIPKEY passes through all SPKM-3 outputs unchanged (including mech_type=SPKM-3), effectively bypassing LIPKEY entirely, because LIPKEY context tokens have no provision for anonymous initiators and SPKM-3 alone suffices.
id-sha1 is a MANDATORY One-Way Function for Subkey Derivation (O-ALG) in SPKM-3, replacing MD5 (which is mandatory in SPKM-1) due to weaknesses found in MD5 when used as a hash.
If the REQ-TOKEN has an algId of NULL-MAC, the SPKM-3 target MUST compute rep-ti-integ over the concatenation of req-contents and rep-ti-contents (rather than just rep-ti-contents).
If the SPKM-3 initiator cannot calculate req-integrity due to lacking the target's certificate, it MUST use NULL-MAC in the REQ-TOKEN algId field, producing a zero-length bit string in the Integrity field.
In the REQ-TOKEN Conf-Algs field, if the SPKM-3 implementation supports an algorithm weaker than cast5CBC, cast5CBC MUST be listed first to encourage negotiation of the stronger algorithm.
In the REQ-TOKEN Intg-Algs field, if SPKM-3 supports an algorithm weaker than HMAC-MD5, HMAC-MD5 MUST be listed first; the initiator must use a MAC algorithm (not a non-repudiation algorithm) since it will be anonymous at the SPKM-3 level.
md5WithRSAEncryption and sha1WithRSAEncryption are RECOMMENDED (not mandatory) integrity algorithms for SPKM-3 due to RSA intellectual property considerations, despite their wide deployment in existing PKI certificates.
SPKM-3 implementations MUST set the target-certif-data-required bit to 1 in the REQ-TOKEN Options field when dhKeyAgreement is the only K-ALG in the key-estb-set, which normally occurs when the implementation cannot resolve the target name to a certificate.
SPKM-3 MUST support cast5CBC as the mandatory confidentiality algorithm with a keyLength of 128 bits, because 56-bit DES is inadequate and LIPKEY requires strong encryption to protect the password transmitted to the target.
SPKM-3 MUST support dhKeyAgreement as a required key establishment algorithm because RSAEncryption requires knowing the target's certificate, which is unavailable in the low-infrastructure deployment model.
SPKM-3 MUST support HMAC-MD5 as a mandatory integrity algorithm (MAC) because DES-MAC's 56-bit security is inadequate and the initiator, being anonymous at the SPKM-3 level, cannot use digital signature algorithms after context establishment.
SPKM-3 MUST support the NULL-MAC integrity algorithm, which returns a zero-length bit string regardless of input, to handle cases where the initiator cannot calculate an integrity value in the REQ-TOKEN due to lack of a target certificate.
The SPKM-3 target MUST NOT use NULL-MAC in its REP-TI-TOKEN algId; it MUST use a signature algorithm such as id-dsa-with-sha1, md5WithRSAEncryption, or sha1WithRSAEncryption.
When LIPKEY calls SPKM-3 GSS_Init_sec_context, it MUST pass claimant_cred_handle=NULL, mutual_req_flag=FALSE, anon_req_flag=TRUE, input_token=NULL, and mech_type set to the SPKM-3 OID.
LIPKEY is a GSS-API mechanism layered above SPKM-3 that provides a low infrastructure security model: the server authenticates via public key certificate, and the client authenticates with a user name and password transmitted over an encrypted channel.
SPKM-3 is a new mechanism type derived from SPKM-1 with a distinct OID: {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) spkm(1) spkm-3(3)}. It is required as the underlying mechanism for LIPKEY.
The LIPKEY mechanism OID is {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) lipkey(9)}.
Although MD5 has known hash weaknesses (Dobbertin 1996), these weaknesses do not affect the security of HMAC-MD5, so HMAC-MD5 remains secure for its role as the mandatory integrity MAC in SPKM-3.
cast5CBC is considered advisable as the mandatory SPKM-3 encryption algorithm: it is a 128-bit cipher, the basis for the cast6CBC algorithm evaluated by NIST as having 'high security margin' with no major or minor security gaps, though smart-card implementation vulnerabilities apply to many algorithms and LIPKEY is not targeted at smart-card environments.
The initiator MUST NOT silently accept a certificate signed by an unknown or untrusted CA when verifying the SPKM-3 target's rep-ti-integ; if it wishes to accept such a certificate, it MUST obtain explicit confirmation from the user.
The target MUST clear all primary and secondary storage (including disk) buffers containing the plaintext password and any password hash immediately after validating the user's credentials, because LIPKEY transmits the cleartext password encrypted with 128-bit cast5CBC and the main residual risk is improper password management on the server.
LIPKEY context establishment (non-anonymous initiator) has four phases: (1) initiator sends SPKM-3 REQ-TOKEN wrapped in LIPKEY token; (2) target replies with SPKM-3 REP-TI-TOKEN, returning GSS_S_CONTINUE_NEEDED; (3) initiator sends GSS_Wrap'd UserName-Password; (4) target validates and replies with GSS_Wrap'd Valid-UNP boolean, completing or failing LIPKEY context establishment.
The LIPKEY post-SPKM-3-establishment initiator token is the output of GSS_Wrap (conf_req=TRUE) applied by the SPKM-3 context to a UserName-Password ASN.1 SEQUENCE containing user-name (OCTET STRING, UTF-8) and password (OCTET STRING, UTF-8).
The LIPKEY target's response token after receiving the UserName-Password is the output_message of an SPKM-3 GSS_Wrap applied to a Valid-UNP BOOLEAN value (TRUE = credentials accepted, FALSE = rejected).
The SPKM QOP is a 32-bit field split into Confidentiality (bits 31-16) and Integrity (bits 15-0), each with subfields TS(5), U(3), IA(4), MA(4). SPKM-3 adds cast5CBC (MA=0010) for confidentiality and id-dsa-with-sha1 (MA=0011), HMAC-MD5 (MA=0100), sha1WithRSAEncryption (MA=0101) for integrity.