RFC 2847

LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM

📅 published June 2000, from ietf

RFC 2847 💖 LIPKEY, A Low Infrastructure Public Key Mechanism Using SPKM 🎀

okay bestie, this one is from the Network Working Group 🌸 It was written by M. Eisler at Zambeel, it's a Standards Track doc, and it dropped in June 2000 ✨ Its header doesn't list any RFCs it obsoletes or updates, so it's not replacing or patching anything older 🦋

Status of this Memo 📋

This doc specifies an Internet standards track protocol for the Internet community, and it wants discussion and suggestions for improvements 💅 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 👑 Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2000). All Rights Reserved. 🧚

Abstract ✨

okay so this memo explains how to use GSS-API [RFC2078] to set up a secure channel between a client and a server 🔐 The client authenticates with a password, and the server authenticates with a public key certificate 💜 It's basically the same vibe as the common low infrastructure use of Transport Layer Security (TLS) protocol [RFC2246], so it's giving TLS energy 🦋

The method builds on the existing Simple Public Key Mechanism (SPKM) [RFC2025]. It's specified as its own separate GSS-API mechanism (LIPKEY), layered on top of SPKM 🍓

Table of Contents 📚

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  LIPKEY's Requirements of SPKM  . . . . . . . . . . . . . . . . 4
   2.1.  Mechanism Type . . . . . . . . . . . . . . . . . . . . . . . 4
   2.2.  Name Type  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.3.  Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 5
   2.3.1.  MANDATORY Algorithms . . . . . . . . . . . . . . . . . . . 5
   2.3.2.  RECOMMENDED Integrity Algorithms (I-ALG) . . . . . . . . . 7
   2.4.  Context Establishment Tokens . . . . . . . . . . . . . . . . 8
   2.4.1.  REQ-TOKEN Content Requirements . . . . . . . . . . . . . . 8
   2.4.1.1.  algId and req-integrity  . . . . . . . . . . . . . . . . 8
   2.4.1.2.  Req-contents . . . . . . . . . . . . . . . . . . . . . . 8
   2.4.1.2.1.  Options  . . . . . . . . . . . . . . . . . . . . . . . 9
   2.4.1.2.2.  Conf-Algs  . . . . . . . . . . . . . . . . . . . . . . 9
   2.4.1.2.3.  Intg-Algs  . . . . . . . . . . . . . . . . . . . . . . 9
   2.4.2.  REP-TI-TOKEN Content Requirements  . . . . . . . . . . . . 9
   2.4.2.1.  algId  . . . . . . . . . . . . . . . . . . . . . . . . . 9
   2.4.2.2.  rep-ti-integ . . . . . . . . . . . . . . . . . . . . . . 9
   2.5.  Quality of Protection (QOP)  . . . . . . . . . . . . . . . .10
   3.  How LIPKEY Uses SPKM . . . . . . . . . . . . . . . . . . . .  11
   3.1.  Tokens . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   3.2.  Initiator  . . . . . . . . . . . . . . . . . . . . . . . .  11
   3.2.1.  GSS_Import_name  . . . . . . . . . . . . . . . . . . . .  11
   3.2.2.  GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . .  11
   3.2.3.  GSS_Init_sec_context . . . . . . . . . . . . . . . . . .  12
   3.2.3.1.  LIPKEY Caller Specified anon_req_flag as TRUE  . . . .  12
   3.2.3.2.  LIPKEY Caller Specified anon_req_flag as FALSE . . . .  13
   3.2.4.  Other operations . . . . . . . . . . . . . . . . . . . .  14
   3.3.  Target . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   3.3.1.  GSS_Import_name  . . . . . . . . . . . . . . . . . . . .  14
   3.3.2.  GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . .  14
   3.3.3.  GSS_Accept_sec_context . . . . . . . . . . . . . . . . .  15
   4.  LIPKEY Description . . . . . . . . . . . . . . . . . . . . .  15
   4.1.  Mechanism Type . . . . . . . . . . . . . . . . . . . . . .  15
   4.2.  Name Types . . . . . . . . . . . . . . . . . . . . . . . .  15
   4.3.  Token Formats  . . . . . . . . . . . . . . . . . . . . . .  16
   4.3.1.  Context Tokens . . . . . . . . . . . . . . . . . . . . .  16
   4.3.1.1.  Context Tokens Prior to SPKM-3 Context Establishment .  16
   4.3.1.2.  Post-SPKM-3 Context Establishment Tokens . . . . . . .  16
   4.3.1.2.1.  From LIPKEY Initiator  . . . . . . . . . . . . . . .  17
   4.3.1.2.2.  From LIPKEY Target . . . . . . . . . . . . . . . . .  17
   4.3.2.  Tokens from GSS_GetMIC and GSS_Wrap  . . . . . . . . . .  17
   4.4.  Quality of Protection  . . . . . . . . . . . . . . . . . .  18
   5.  Security Considerations  . . . . . . . . . . . . . . . . . .  18
   5.1.  Password Management  . . . . . . . . . . . . . . . . . . .  18
   5.2.  Certification Authorities  . . . . . . . . . . . . . . . .  18
   5.3.  HMAC-MD5 and MD5 Weaknesses  . . . . . . . . . . . . . . .  18
   5.4.  Security of cast5CBC . . . . . . . . . . . . . . . . . . .  18
   References . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .  21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . .  21
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  22

1. Introduction 🌷

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖

This memo introduces a brand new security mechanism for GSS-API, called the Low Infrastructure Public Key Mechanism (LIPKEY) 🦄 GSS-API lets an application protocol bring in authentication, integrity, and privacy. TLS is another option 💅 TLS is way easier for an app to plug in than GSS-API, honestly, but GSS-API can be the better pick in some situations 🫶

It's definitely true for application protocols that run over connectionless protocols ✨ Same deal for stuff like ONC RPC [RFC1831] [RFC2203], which already has its own security architecture. So it doesn't mesh easily with TLS, which is a layer that wraps the whole upper-layer application protocol 🎀 GSS-API lets the app protocol wrap as much of itself as it needs 🧚

Okay, but here's the tea. GSS-API is super flexible, but people tend to think it needs way more infrastructure to deploy than TLS does, and that's kinda rough 😭 The best-known GSS-API mechanisms, Kerberos V5 [RFC1964] and SPKM, need a ton of infrastructure to get set up 💀 Picture the typical TLS setup instead: a client with no public key certificate hitting a server that has one. The client:

  • obtains the server's certificate,
  • verifies that it was signed by a trusted Certification Authority (CA),
  • generates a random session symmetric key,
  • encrypts the session key with the server's public key, and
  • sends the encrypted session key to the server.

Now the client and server have a secure channel, yay 🥹 The client can then send a user name and password to the server so the server can authenticate the client. Like, with TLS and http, once the channel is secure, the http server shows the client an html page asking for a user name and password. That info gets encrypted with the session key and sent over, and then the server authenticates the client 🔥

Note that the client is not required to have a certificate for itself to identify and authenticate it to the server 🙈 Besides TLS, the required security infrastructure includes a public key certificate and password database on the server, plus a list of trusted CAs and their public keys on the client. Most operating systems that the http server would run on already have a native password database, so the net additional infrastructure is just a server certificate and CA list. That's why it's called the "low infrastructure security model" for this typical TLS deployment scenario 🌸

By using unilateral authentication, and a mechanism that resembles the SPKM-1 mechanism type, SPKM can offer many aspects of that low infrastructure security model 🦋 An application that uses GSS-API is totally free to use the GSS_Wrap() routine to encrypt a user name and password and send them to the server, so the server can decrypt and verify them 🍓

Applications often have application protocols attached, and the protocol might not have any provision for specifying a password 😬 Layering a thin GSS-API mechanism over a mechanism that resembles SPKM-1 can fix that. It's a useful approach when you want to avoid modifying applications that are already bound to GSS-API, as long as those applications aren't statically bound to specific GSS-API mechanisms 💜 The rest of this memo defines that thin mechanism: the Low Infrastructure Public Key Mechanism (LIPKEY) 👑

2. LIPKEY's Requirements of SPKM 🎀

SPKM-1 with unilateral authentication is already pretty close to the low infrastructure model we just talked about 🥰 This section covers some extra changes to how SPKM-1 operates so it can actually hit that model. The changes include some minor tweaks in semantics. You could build these semantic changes into an SPKM-1 implementation (even reusing the same mechanism type Object Identifier (OID) as SPKM-1), but the changes stretch the interpretation of RFC 2025 so far that compatibility would be in danger 😭 So a new mechanism type, called SPKM-3, is warranted ✨ LIPKEY requires that the SPKM implementation support SPKM-3. SPKM-3 is equivalent to SPKM-1, except as described in the rest of this section 💅

2.1. Mechanism Type 🧚

SPKM-3 has a different mechanism type OID from SPKM-1 🦄 The OID is:

   spkm-3 OBJECT IDENTIFIER ::=
      {iso(1)identified-organization(3)dod(6)internet(1)security(5)
      mechanisms(5)spkm(1)spkm-3(3)}

2.2. Name Type 🍓

RFC 2025 doesn't define any required name types for SPKM, so there's nothing to match there 🙈 LIPKEY requires that the SPKM-3 implementation support all the mechanism independent name types in RFC 2078 💖

2.3.1. MANDATORY Algorithms 💅

okay so RFC 2025 is basically the big algorithm menu 🍓 It covers integrity, confidentiality, key establishment, and subkey derivation. Except for md5WithRSAEncryption, the REQUIRED Key Establishment (K-ALG), Integrity (I-ALG) and One-Way Functions for Subkey Derivation (O-ALG) algorithms listed in RFC 2025 continue to be REQUIRED. ✨

SPKM is designed to be extensible with regard to new algorithms. 🦋 But for LIPKEY to work correctly and securely, the following algorithms MUST be implemented in SPKM-3:

Integrity algorithms (I-ALG) 🔐

NULL-MAC

Because the initiator may not have a certificate for itself, nor for the target, it is not possible for it to calculate an Integrity value in the initiator's REQ-TOKEN that is sent to the target. So we define, in ASN.1 [CCITT] syntax, a null I-ALG that returns a zero length bit string regardless of the input passed to it:

NULL-MAC OBJECT IDENTIFIER ::=
   {iso(1)identified-organization(3)dod(6)internet(1)security(5)
   integrity(3)NULL-MAC(3)}

id-dsa-with-sha1

This is the signature algorithm as defined in Section 7.2.2 of [RFC2459]. As noted in RFC 2459, the ASN.1 OID used to identify this signature algorithm is:

id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) x9-57(10040)
                x9cm(4) 3
}

Note that there is a work-in-progress [PKIX] to obsolete RFC 2459. However, that work-in-progress does not change the definition of id-dsa-with-sha1. 🌸

HMAC-MD5

A consequence of the SPKM-3 initiator not having a certificate is that it cannot use a digital signature algorithm like md5WithRSAEncryption, id-dsa-with-sha1, or sha1WithRSAEncryption once the context is established. 🙈 Instead, a message authentication code (MAC) algorithm is required. DES-MAC is specified as recommended in [RFC2025]. Since the security of 56 bit DES has been shown to be inadequate [EFF], SPKM-3 needs a stronger MAC. Thus, SPKM-3 MUST support the HMAC-MD5 algorithm [RFC2104], with this OID:

HMAC-MD5 OBJECT IDENTIFIER ::= {
        iso(1) org(3) dod(6) internet(1) security(5)
                mechanisms(5) ipsec(8) isakmpOakley(1)
                1
}

The reference for the algorithm OID of HMAC-MD5 is [IANA]. The reference for the HMAC-MD5 algorithm is [RFC2104].

The HMAC-SHA1 algorithm is not a mandatory SPKM-3 I-ALG MAC because SHA-1 is about half the speed of MD5 [Young]. A MAC based on an encryption algorithm like cast5CBC, DES EDE3, or RC4 is not mandatory because MD5 is 31 percent faster than the fastest of the three encryption algorithms [Young]. 🏃‍♀️

Confidentiality algorithm (C-ALG) 🔒

RFC 2025 does not have a MANDATORY confidentiality algorithm, and instead has RECOMMENDED a 56 bit DES algorithm. Since the LIPKEY initiator needs to send a password to the target, and since 56 bit DES has been demonstrated as inadequate [EFF], LIPKEY needs stronger encryption. Thus, SPKM-3 MUST support this algorithm:

cast5CBC OBJECT IDENTIFIER ::= {
        iso(1) memberBody(2) usa(840) nt(113533) nsn(7)
                algorithms(66) 10
}

Parameters ::= SEQUENCE {
        iv OCTET STRING DEFAULT 0, -- Initialization vector
        keyLength INTEGER          -- Key length, in bits
}

The reference for the OID and description of the cast5CBC algorithm is [RFC2144]. The keyLength in the Parameters MUST be set to 128 bits.

A triple DES (DES EDE3) algorithm is not a mandatory SPKM-3 C-ALG because it is much slower than cast5CBC. 🐢 One set of measurements [Young] on a Pentium Pro 200 megahertz processor using the SSLeay code showed that DES EDE3 performed as high as 1,646,210 bytes per second, using 1024 byte blocks. The same test bed yielded performance of 7,147,760 bytes per second for cast5CBC, and 22,419,840 bytes per second for RC4. Most TLS sessions negotiate the RC4 cipher. Given that LIPKEY is targeted at environments similar to those where TLS is deployed, selecting a cipher that is over 13 times slower (and over 13 times more CPU intensive) than RC4 would severely impede the usefulness of LIPKEY. 😭 For performance reasons, RC4 would be the preferred mandatory algorithm for SPKM-3. Due to intellectual property considerations with RC4 [Schneier], the combination of cast5CBC's reasonable performance, and its royalty-free licensing terms [RFC2144], make cast5CBC the optimal choice among DES EDE3, RC4, and cast5CBC. 👑

Key Establishment Algorithm (K-ALG) 🗝️

RFC 2025 lists dhKeyAgreement [PKCS-3] as an apparently optional algorithm. As will be described later, the RSAEncryption key establishment algorithm is of no use for a low infrastructure security mechanism as defined by this memorandum. Hence, in SPKM-3, dhKeyAgreement is a REQUIRED key establishment algorithm:

dhKeyAgreement OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
        pkcs-3(3) 1
}

One-Way Function for Subkey Derivation Algorithm (O-ALG) 🧁

RFC 2025 lists MD5 as a mandatory algorithm. Since MD5 has been found to have weaknesses when used as a hash [Dobbertin], id-sha1 is a MANDATORY O-ALG in SPKM-3:

id-sha1 OBJECT IDENTIFIER ::= {
        iso(1) identified-organization(3) oiw(14)
        secsig(3) algorithms(2) 26
}

The reference for the algorithm OID of id-sha1 is [RFC2437]. The reference for the SHA-1 algorithm corresponding to id-sha1 is [FIPS].

md5WithRSAEncryption

The md5WithRSAEncryption integrity algorithm is listed in [RFC2025] as mandatory. Due to intellectual property considerations [RSA-IP], SPKM-3 implementations cannot be required to implement it. However, given the proliferation of certificates using RSA public keys, md5WithRSAEncryption is strongly RECOMMENDED. Otherwise, the opportunities for LIPKEY to leverage existing public key infrastructure will be limited. 🥺

sha1WithRSAEncryption

For reasons similar to those for md5WithRSAEncryption, sha1WithRSAEncryption is a RECOMMENDED algorithm. The sha1WithRSAEncryption algorithm is listed in addition to md5WithRSAEncryption due to weaknesses in the MD5 hash algorithm [Dobbertin]. The OID for sha1WithRSAEncryption is:

sha1WithRSAEncryption  OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
        pkcs-1(1) 5
}

The reference for the algorithm OID and description of sha1WithRSAEncryption is [RFC2437].

2.4. Context Establishment Tokens 🎀

RFC 2025 sets up a context with an initiator first token (REQ-TOKEN), a target reply (REP-TI-TOKEN), and finally an initiator second token (REP-IT-TOKEN) to reply to the target's reply. Since LIPKEY uses SPKM-3 with unilateral authentication, the REP-IT-TOKEN is not used. LIPKEY has certain requirements on the contents of the REQ-TOKEN and REP-TI-TOKEN, but the syntax of the SPKM-3 tokens is not different from RFC 2025's SPKM-1 tokens. 💖

2.4.1. REQ-TOKEN Content Requirements 📝

2.4.1.1. algId and req-integrity

If the SPKM-3 initiator cannot calculate a req-integrity field due to the lack of a target certificate, it MUST use the NULL-MAC I-ALG described earlier in this memorandum. This will produce a zero length bit string in the Integrity field.

2.4.1.2. Req-contents

Because RFC 2025 requires that the RSAEncryption K-ALG be present, SPKM-1 must be able to map the target (targ-name) to its public key certificate, and thus SPKM can use the RSAEncryption algorithm to fill in the key-estb-req field. Because LIPKEY assumes a low infrastructure deployment, SPKM-3 MUST be prepared to be unable to map the targ-name field of the Req-contents field. This is a contradiction which is resolved by requiring SPKM-3 to support the dhKeyAgreement algorithm. Note that if an SPKM-3 implementation tries to map the target to a certificate, and succeeds, it is free to use the RSAEncryption K-ALG algorithm. It is also free to use an algID other than NULL-MAC in the REQ-TOKEN type. 🧩

2.4.1.2.1. Options

SPKM-3 implementations MUST set the target-certif-data-required bit to 1 if the only K-ALG in the key-estb-set field of Req-contents is dhKeyAgreement. This would normally occur if the SPKM-3 implementation cannot resolve the target name to a certificate. 🙌

2.4.1.2.2. Conf-Algs

If the SPKM-3 implementation supports an algorithm weaker than cast5CBC, cast5CBC MUST be listed before the weaker algorithm to encourage the target to negotiate the stronger algorithm. 💪

2.4.1.2.3. Intg-Algs

Because the initiator will be anonymous (at the SPKM-3 level) and will not have a certificate for itself, the initiator cannot use an integrity algorithm that supports non-repudiation; it must use a MAC algorithm. If the SPKM-3 implementation supports an algorithm weaker than HMAC-MD5, HMAC-MD5 MUST be listed before the weaker algorithm to encourage the target to negotiate the stronger algorithm. 🛡️

2.4.2. REP-TI-TOKEN Content Requirements 🌷

With the previously described requirements on REQ-TOKEN, the contents of SPKM-3's REP-TI-TOKEN can for the most part be derived from the specification in RFC 2025. The exceptions are the algId and rep-ti-integ fields. ✨

2.4.2.1. algId

The SPKM-3 target MUST NOT use a NULL-MAC I-ALG; it MUST use a signature algorithm like id-dsa-with-sha1, md5WithRSAEncryption, or sha1WithRSAEncryption. 🚫

2.4.2.2. rep-ti-integ

If the req-token has an algId of NULL-MAC, then the target MUST compute the rep-ti-integ on the concatenation of the req-contents and rep-ti-contents. 🫶

2.5. Quality of Protection (QOP) 🎀

okay so bestie, QOP is where the initiator and target pick their algorithms 💅 They negotiate the set of algorithms they both support, using the procedure in Section 5.2 of RFC 2025 🫶 If a QOP of zero is specified, then the initiator and target will use the first C-ALG (privacy) and I-ALG (integrity) algorithms that got negotiated ✨

SPKM splits the QOP into several fields, and here's the layout straight from Section 5.2 of RFC 2025 🧚

       Confidentiality                    Integrity
       31 (MSB)                        16 15                 (LSB) 0
      -------------------------------|-------------------------------
      | TS(5) | U(3) | IA(4) | MA(4) | TS(5) | U(3) | IA(4) | MA(4) |
      -------------------------------|-------------------------------

The MA subfields list the mechanism-defined algorithms. Since this memorandum introduces a new mechanism, SPKM-3, inside the SPKM family, it makes sense to add algorithms to the MA subfields of the Confidentiality and Integrity fields 🦋

The complete set of Confidentiality MA algorithms is thus:

      0001 (1) = DES-CBC
      0010 (2) = cast5CBC

Where "0001" and "0010" are in base 2. An SPKM peer that negotiates a confidentiality MA algorithm value of "0010" MUST use a 128 bit key, i.e. set the keyLength values in the cast5CBC Parameters to 128 bits. This part is a must-do, no cap 🔥

The complete set of Integrity MA algorithms is thus:

      0001 (1) = md5WithRSAEncryption
      0010 (2) = DES-MAC
      0011 (3) = id-dsa-with-sha1
      0100 (4) = HMAC-MD5
      0101 (5) = sha1WithRSAEncryption

Where "0001" through "0101" are in base 2.

Adding support for cast5CBC, id-dsa-with-sha1, HMAC-MD5, and sha1WithRSAEncryption in the above manner to SPKM-1 and SPKM-2 does not impair SPKM-1 and SPKM-2 backward compatibility, because (as noted previously) SPKM negotiates algorithms. An older SPKM-1 or SPKM-2 that doesn't recognize MA values for cast5CBC, id-dsa-with-sha1, HMAC-MD5, or sha1WithRSAEncryption simply won't select them. Old versions stay in their lane, and that's iconic behavior 💖

3. How LIPKEY Uses SPKM 🌈

3.1. Tokens

LIPKEY will invoke SPKM-3 to produce SPKM tokens. Since the mechanism the application uses is LIPKEY, LIPKEY will wrap some of the SPKM-3 tokens with LIPKEY prefixes. The exact definition of the tokens is described later in this memorandum 🧁

3.2. Initiator

3.2.1. GSS_Import_name

The initiator uses GSS_Import_name to import the target's name, typically (but not necessarily) using the GSS_C_NT_HOSTBASED_SERVICE name type. Ultimately, the output of GSS_Import_name will apply to an SPKM-3 mechanism type, because a LIPKEY target is an SPKM-3 target 🦋

3.2.2. GSS_Acquire_cred

The initiator calls GSS_Acquire_cred. The credentials that get acquired are LIPKEY credentials, a user name and password. How the user name and password get acquired depends on the operating environment. An application that invokes GSS_Acquire_cred() while the application's user has a graphical user interface running might trigger a pop-up window that prompts for the information. An application embedded into the operating system, such as an NFS [Sandberg] client implemented as a native file system, might broadcast a message to the user's terminals telling them to invoke a command that prompts for the information 💻

Because the credentials won't be used until GSS_Init_sec_context is called, the LIPKEY implementation will need to safeguard the credentials 🔐 If this is a problem, the implementation may instead defer the actual acquisition of the user name and password until GSS_init_sec_context is ready to send the user name and password to the target. In that event, the output_cred_handle argument of GSS_Acquire_cred would simply be a reference that maps to the principal corresponding to the desired_name argument. A subsequent GSS_Init_sec_context call would consider the mapping of claimant_cred_handle to the principal when it acquires the user name and password. For example, the aforementioned pop-up window might fill in the user name portion of the dialog with a default value that maps to the principal referred to in claimant_cred_handle 🌸

3.2.3. GSS_Init_sec_context

When a program invokes GSS_Init_sec_context on the LIPKEY mechanism type, and the context handle is NULL, the LIPKEY mechanism will in turn invoke GSS_Init_sec_context on an SPKM-3 mechanism implemented according to the requirements described previously. This call to SPKM-3 MUST have the following attributes:

  • claimant_cred_handle is NULL
  • mutual_req_flag is FALSE
  • anon_req_flag is TRUE
  • input_token is NULL
  • mech_type is the OID of the SPKM-3 mechanism

Keep in mind that the above attributes are in the GSS_Init_sec_context call from the LIPKEY mechanism down to the SPKM-3 mechanism. There are no special restrictions placed on the application invoking LIPKEY's GSS_Init_sec_context routine. All other arguments are derived from the LIPKEY GSS_Init_sec_context arguments 🧚

The call to the SPKM-3 GSS_Init_sec_context will create an SPKM-3 context handle. The rest of the description of the LIPKEY GSS_Init_sec_context call depends on whether the caller of the LIPKEY GSS_Init_sec_context sets anon_req_flag to TRUE or FALSE 👑

3.2.3.1. LIPKEY Caller Specified anon_req_flag as TRUE

If the caller of LIPKEY's GSS_Init_sec_context sets anon_req_flag to TRUE, it MUST return to the LIPKEY caller all the outputs from the SPKM-3 GSS_Init_sec_context call, including the output_context_handle, output_token, and mech_type. This way, LIPKEY "gets out of the way" of GSS-API processing between the application and SPKM-3, because nothing in the returned outputs relates to LIPKEY. This is necessary, because LIPKEY context tokens don't have provision for specifying anonymous initiators. That's because SPKM-3 is sufficient for supporting anonymous initiators in a low infrastructure environment 🙈

Clearly, when the LIPKEY caller wants anonymous authentication, LIPKEY doesn't add any value. But it's simpler to support the feature than to insist the caller use SPKM-3 directly 💅

If all goes well, the caller of LIPKEY will be returned a major_status of GSS_S_CONTINUE_NEEDED via SPKM-3, so the caller of LIPKEY will send the output_token to the target. The caller of LIPKEY then receives the response token from the target, and directly invokes the SPKM-3 GSS_Init_sec_context. Upon return, the major_status should be GSS_S_COMPLETE ✨

3.2.3.2. LIPKEY Caller Specified anon_req_flag as FALSE

The LIPKEY mechanism will need to allocate a context handle for itself, and record in the LIPKEY context handle the SPKM-3 context handle that was returned in the output_context_handle parameter from the call to the SPKM-3 GSS_Init_sec_context routine. The LIPKEY GSS_Init_sec_context routine will return the LIPKEY context handle in output_context_handle, and the LIPKEY mechanism type in mech_type. The output_token is as defined later in this memorandum, in the subsection entitled "Context Tokens Prior to SPKM-3 Context Establishment." All the other returned outputs will be those that the SPKM-3 GSS_Init_sec_context routine returned to LIPKEY. If all went well, the SPKM-3 mechanism will have returned a major_status of GSS_S_CONTINUE_NEEDED 🌈

The caller of the LIPKEY GSS_Init_sec_context routine will see a major_status of GSS_S_CONTINUE_NEEDED, so the caller of LIPKEY will send the output_token to the target. The caller of LIPKEY then receives the target's response token, and invokes the LIPKEY GSS_Init_sec_context routine a second time. LIPKEY then invokes the SPKM-3 GSS_Init_sec_context a second time, and upon return, the major_status should be GSS_S_COMPLETE 🎀

While SPKM-3's context establishment is now complete, LIPKEY's context establishment is not finished yet, because the initiator must send the target the user name and password that were passed to it via claimant_cred_handle on the first call to the LIPKEY GSS_Init_sec_context routine. LIPKEY uses the established SPKM-3 context handle as the input to GSS_Wrap (with conf_req_flag set to TRUE) to encrypt what claimant_cred_handle refers to (the user name and password). It returns that as the output_token to the caller of LIPKEY (provided the conf_state output from the call to SPKM-3's GSS_Wrap is TRUE), along with a major_status of GSS_S_CONTINUE_NEEDED 🔥

The caller of LIPKEY sends its second context establishment token to the target, and waits for a token provided by the target's GSS_Accept_sec_context routine. The target's LIPKEY GSS_Accept_sec_context routine invokes the SPKM-3 GSS_Unwrap routine on the token, and validates the user name and password. The target then invokes SPKM-3's GSS_Wrap routine on a boolean indicating whether or not the user name and password were accepted, and returns the output_message result from GSS_Wrap as the output_token result for GSS_Accept_sec_context 🫶

The caller of LIPKEY receives the target's response token, and passes it via the input_token parameter to the LIPKEY GSS_Init_sec_context routine. LIPKEY then invokes GSS_Unwrap to get the boolean acceptance indication, and maps this to a major_status of either GSS_S_COMPLETE (indicating success, the boolean was TRUE, and LIPKEY context establishment is completed) or GSS_S_FAILURE (indicating that context establishment failed). GSS_S_CONTINUE_NEEDED will not be returned 💀

Note that the mutual_req_flag parameter is ignored, because unilateral authentication is impossible. The initiator must authenticate the target via SPKM-3 in order to create a secure channel to transmit the user name and password. The target must authenticate the initiator when it receives the user name and password 🔐

The SPKM-3 context remains established while the LIPKEY context is established. If the SPKM-3 context expires before the LIPKEY context is destroyed, the LIPKEY implementation should expire the LIPKEY context and return the appropriate error on the next GSS-API operation ⭐

3.2.4. Other operations

For other operations, the LIPKEY context acts as a pass-through to the SPKM-3 context. Operations that affect or inquire about context state, such as GSS_Delete_sec_context, GSS_Export_sec_context, GSS_Import_sec_context, and GSS_Inquire_context, will require a pass-through to the SPKM-3 context and a state modification of the LIPKEY context 🦋

3.3. Target

3.3.1. GSS_Import_name

As with the initiator, the imported name will be that of the target 🌸

3.3.2. GSS_Acquire_cred

The target calls the LIPKEY GSS_Acquire_cred routine to get a credential for an SPKM-3 target, via the SPKM-3 GSS_Acquire_cred routine. The desired_name is the output_name from GSS_Import_name 🧚

3.3.3. GSS_Accept_sec_context

Okay so when a program calls GSS_Accept_sec_context on the LIPKEY mechanism type 💅 and the context handle is NULL, LIPKEY turns around and calls GSS_Accept_sec_context on an SPKM-3 mechanism set up according to the requirements we went over earlier ✨. This call to SPKM-3 is totally normal, exactly what you'd expect from a layered call to GSS_Accept_sec_context. No surprises here 🫶

If everything goes well 🌸, the SPKM-3 GSS_Accept_sec_context call comes back with GSS_S_COMPLETE, and the LIPKEY call hands the output_token back to the caller. But its major_status is GSS_S_CONTINUE_NEEDED 🙈, because the LIPKEY initiator still has to send over the user name and password.

Once the SPKM-3 context is in a GSS_S_COMPLETE state, the next token the target gets will carry the user name and password, wrapped up by the output of an SPKM-3 GSS_Wrap call 🎀. The target calls LIPKEY GSS_Accept_sec_context, which calls the SPKM-3 GSS_Unwrap routine. Then LIPKEY GSS_Accept_sec_context checks the user name and password against its user name and password database 👀. If they're valid, GSS_S_COMPLETE goes back to the caller. Otherwise it's GSS_S_FAILURE. Either way, an output_token comes back, equal to the output_message result of an SPKM-3 GSS_Wrap call on a boolean value 🦋. That boolean is TRUE if the user name and password were valid, and FALSE otherwise. The target expects no more context establishment tokens from the caller. Done and dusted ✨

4. LIPKEY Description 💜

4.1. Mechanism Type

lipkey OBJECT IDENTIFIER ::=
   {iso(1)identified-organization(3)dod(6)internet(1)security(5)
   mechanisms(5)lipkey(9)}

4.2. Name Types

LIPKEY only uses the mechanism independent name types defined in RFC 2078 🏷️. All the name types defined in RFC 2078 are REQUIRED 💖.

4.3. Token Formats

4.3.1. Context Tokens

GSS-API defines the context tokens like this 🧚:

InitialContextToken ::=
   -- option indication (delegation, etc.) indicated within
   -- mechanism-specific token
   [APPLICATION 0] IMPLICIT SEQUENCE {
          thisMech MechType,
          innerContextToken ANY DEFINED BY thisMech
             -- contents mechanism-specific
             -- ASN.1 structure not required
   }

SubsequentContextToken ::= innerContextToken ANY
   -- interpretation based on predecessor InitialContextToken
   -- ASN.1 structure not required

The contents of the innerContextToken depend on whether the SPKM-3 context is established or not.

4.3.1.1. Context Tokens Prior to SPKM-3 Context Establishment

In a LIPKEY InitialContextToken, thisMech will be the Object identifier for LIPKEY. However, as long as LIPKEY has not established the SPKM-3 mechanism, the innerContextToken for both the InitialContextToken and the SubsequentContextToken will be the output of an SPKM-3 GSS_Init_sec_context or GSS_Accept_sec_context. So the LIPKEY innerContextToken would be either:

  • An InitialContextToken, with thisMech set to the object identifier for SPKM-3, with innerContextToken defined to be an SPKMInnerContextToken, as defined in RFC 2025.
  • A SubsequentContextToken, with innerContextToken defined to be SPKMInnerContextToken

4.3.1.2. Post-SPKM-3 Context Establishment Tokens

Once the SPKM-3 context is established, there is just one token sent from the initiator to the target, and one token returned to the initiator. Simple and clean 🌈

4.3.1.2.1. From LIPKEY Initiator

The LIPKEY initiator generates a token that is the result of a GSS_Wrap (conf_req is set to TRUE) of a user name and password by the SPKM-3 context. The input_message argument of GSS_Wrap refers to an instance of the UserName-Password type defined below:

UserName-Password ::= SEQUENCE {
        user-name       OCTET STRING,
                                -- each octet is an octet of a
                                -- UTF-8 [RFC2279] string
        password        OCTET STRING
                                -- each octet is an octet of a
                                -- UTF-8 [RFC2279] string
}

4.3.1.2.2. From LIPKEY Target

The target validates the user name and password token from the initiator, and generates a response token that is the output_message result of an SPKM-3 GSS_Wrap (conf_req may or may not be set to TRUE) call on an indication of validation success. The input_message argument of GSS_Wrap refers to an instance of the Valid-UNP type defined below:

Valid-UNP ::= BOOLEAN
                   -- If TRUE, user name/password pair was valid.

4.3.2. Tokens from GSS_GetMIC and GSS_Wrap

RFC 2078 defines the token emitted by GSS_GetMIC and GSS_Wrap as:

          PerMsgToken ::=
          -- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
          -- ASN.1 structure not required
                  innerMsgToken ANY

          SealedMessage ::=
          -- as emitted by GSS_Wrap and processed by GSS_Unwrap
          -- includes internal, mechanism-defined indicator
          -- of whether or not encrypted
          -- ASN.1 structure not required
                  sealedUserData ANY

As one can see, there are no mechanism independent prefixes in PerMSGToken or SealedMessage, and no explicit mechanism specific information. Since LIPKEY doesn't add any value to GSS_GetMIC and GSS_Wrap other than passing the message along to the SPKM-3 GSS_GetMIC and GSS_Wrap routines, LIPKEY's PerMsgToken and SealedMessage tokens are exactly what SPKM-3's GSS_GetMIC and GSS_Wrap routines produce 🍓

4.4. Quality of Protection

LIPKEY, being a pass through for GSS_Wrap and GSS_GetMIC to SPKM-3, does not interpret or alter the QOPs passed to the aforementioned routines or received from their complements, GSS_Unwrap and GSS_VerifyMIC. Thus, LIPKEY supports the same set of QOPs as SPKM-3.

5. Security Considerations 🔥

5.1. Password Management

LIPKEY sends the clear text password encrypted by 128 bit cast5CBC, so the risk here is all about how the target handles the password once it's done with it 🔐. This approach should be safe, provided the target clears the memory (primary and secondary, such as disk) buffers that held the password, and any hash of the password, immediately after it has validated the user's password. Don't skip this part, bestie 😭

5.2. Certification Authorities

The initiator must have a list of trusted Certification Authorities so it can verify the checksum (rep-ti-integ) on the SPKM-3 target's context reply token 🛡️. If it runs into a certificate signed by an unknown and/or untrusted certificate authority, the initiator MUST NOT silently accept the certificate 🚨. And if it does want to accept that certificate, it MUST get confirmation from the user running the application that is using GSS-API. No sneaky accepting, bestie 🙅

5.3. HMAC-MD5 and MD5 Weaknesses

While the MD5 hash algorithm has been found to have weaknesses [Dobbertin], the weaknesses do not impact the security of HMAC-MD5 [Dobbertin] 🦋

5.4. Security of cast5CBC

The cast5CBC encryption algorithm is relatively new compared to established algorithms like triple DES and RC4. Nonetheless, the choice of cast5CBC as the MANDATORY C-ALG for SPKM-3 is advisable 💜. The cast5CBC algorithm is a 128 bit algorithm that the 256 bit cast6CBC [RFC2612] algorithm is based upon. The cast6CBC algorithm was judged by the U.S. National Institute of Standards and Technology (NIST) to have no known major or minor "security gaps," and to have a "high security margin" [AES]. NIST did note some vulnerabilities related to smart card implementations, but many other algorithms NIST analyzed shared the vulnerabilities. And in any case, LIPKEY is by definition not aimed at smart cards which is honestly a relief 🌸

References ✨

Okay bestie, here's the reading list 📚🫶 every source the spec leans on, with all the details so you can go find them yourself:

  • [AES] Nechvatal, J., Barker, E., Dodson, D., Dworkin, M., Foti, J., Roback, E. (Undated, but no later than 1999). "Status Report on the First Round of the Development of the Advanced Encryption Standard." http://csrc.nist.gov/encryption/aes/round1/r1report.htm
  • [CCITT] CCITT (1988). "Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1)."
  • [Dobbertin] Dobbertin, H. (1996). "The Status of Md5 After a Recent Attack," RSA Laboratories' CryptoBytes, Volume 2, Number 2. ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf
  • [EFF] Electronic Frontier Foundation, John Gilmore (Editor) (1998). "Cracking Des: Secrets of Encryption Research, Wiretap Politics & Chip Design," O'Reilly & Associates, ISBN 1565925203.
  • [FIPS] National Institute of Standards and Technology (1995). "Secure Hash Standard" (SHA-1). http://www.itl.nist.gov/fipspubs/fip180-1.htm
  • [IANA] Internet Assigned Numbers Authority (1999). "Network Management Parameters." http://www.isi.edu/in-notes/iana/assignments/smi-numbers
  • [PKCS-3] RSA Laboratories (1993). "PKCS #3: Diffie-Hellman Key-Agreement Standard, Version 1.4." ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-3.asc
  • [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", Work in Progress.
  • [RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995.
  • [RFC1832] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
  • [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
  • [RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
  • [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
  • [RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
  • [RFC2104] Krawczyk, H, Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997.
  • [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
  • [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
  • [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998.
  • [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
  • [RFC2612] Adams, C. and J. Gilchrist, "The CAST-256 Encryption Algorithm", RFC 2612, June 1999.
  • [RSA-IP] All statements received by the IETF Secretariat are placed on-line at http://www.ietf.org/ipr.html. Please check this web page to see any IPR information received about this and other technology.
  • [Sandberg] Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon, B. (1985). "Design and Implementation of the Sun Network Filesystem," Proceedings of the 1985 Summer USENIX Technical Conference.
  • [Schneier] Schneier, B. (1996). "Applied Cryptography," John Wiley & Sons, Inc., ISBN 0-471-11709-9.
  • [Young] Young, E.A. (1997). Collected timing results from the SSLeay source code distribution.

Acknowledgments 🫶

Huge thank-yous to these legends 💖:

  • Jack Kabat, for his patient explanation of the intricacies of SPKM, excellent suggestions, and review comments.
  • Denis Pinkas, for his review comments.
  • Carlisle Adams, for his review comments.
  • John Linn, for his review comments.
  • Martin Rex, for his review comments.
  • This memorandum includes ASN.1 definitions for GSS-API tokens from RFC 2078, which was authored by John Linn.
  • This memorandum includes ASN.1 definitions and other text from the SPKM definition in RFC 2025, which was authored by Carlisle Adams.

Author's Address 🎀

Address comments related to this memorandum to:

ietf-cat-wg@lists.Stanford.EDU

Mike Eisler
Zambeel
5565 Wilson Road
Colorado Springs, CO 80919

Phone: 1-719-599-9026
EMail: mike@eisler.com

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💅

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

📦 where this page comes from