From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2847.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc2847.txt (limited to 'doc/rfc/rfc2847.txt') diff --git a/doc/rfc/rfc2847.txt b/doc/rfc/rfc2847.txt new file mode 100644 index 0000000..8cb6bf6 --- /dev/null +++ b/doc/rfc/rfc2847.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group M. Eisler +Request for Comments: 2847 Zambeel +Category: Standards Track June 2000 + + + LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This memorandum describes a method whereby one can use GSS-API + [RFC2078] to supply a secure channel between a client and server, + authenticating the client with a password, and a server with a public + key certificate. As such, it is analogous to the common low + infrastructure usage of the Transport Layer Security (TLS) protocol + [RFC2246]. + + The method leverages the existing Simple Public Key Mechanism (SPKM) + [RFC2025], and is specified as a separate GSS-API mechanism (LIPKEY) + layered above 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 + + + +Eisler Standards Track [Page 1] + +RFC 2847 LIPKEY June 2000 + + + 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 memorandum describes a new security mechanism under the GSS-API + called the Low Infrastructure Public Key Mechanism (LIPKEY). GSS-API + provides a way for an application protocol to implement + authentication, integrity, and privacy. TLS is another way. While TLS + + + +Eisler Standards Track [Page 2] + +RFC 2847 LIPKEY June 2000 + + + is in many ways simpler for an application to incorporate than GSS- + API, there are situations where GSS-API might be more suitable. + Certainly this is the case with application protocols that run over + connectionless protocols. It is also the case with application + protocols such as ONC RPC [RFC1831] [RFC2203], which have their own + security architecture, and so do not easily mesh with a protocol like + TLS that is implemented as a layer that encapsulates the upper layer + application protocol. GSS-API allows the application protocol to + encapsulate as much of the application protocol as necessary. + + Despite the flexibility of GSS-API, it compares unfavorably with TLS + with respect to the perception of the amount of infrastructure + required to deploy it. The better known GSS-API mechanisms, Kerberos + V5 [RFC1964] and SPKM require a great deal of infrastructure to set + up. Compare this to the typical TLS deployment scenario, which + consists of a client with no public key certificate accessing a + server with a public key certificate. 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. + + At this point, the client and server have a secure channel. The + client can then provide a user name and password to the server to + authenticate the client. For example, when TLS is being used with the + http protocol, once there is a secure channel, the http server will + present the client with an html page that prompts for a user name and + password. This information is then encrypted with the session key and + sent to the server. The server then authenticates the client. + + Note that the client is not required to have a certificate for itself + to identify and authenticate it to the server. In addition to a TLS + implementation, the required security infrastructure includes a + public key certificate and password database on the server, and 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 a + server certificate and CA list. Hence the term "low infrastructure + security model" to identify this typical TLS deployment scenario. + + + + + +Eisler Standards Track [Page 3] + +RFC 2847 LIPKEY June 2000 + + + By using unilateral authentication, and using a mechanism resembling + the SPKM-1 mechanism type, SPKM can offer many aspects of the + previously described low infrastructure security model. An + application that uses GSS-API is certainly free to use GSS-API's + GSS_Wrap() routine to encrypt a user name and password and send them + to the server, for it to decrypt and verify. + + Applications often have application protocols associated with them, + and there might not be any provision in the protocol to specify a + password. Layering a thin GSS-API mechanism over a mechanism + resembling SPKM-1 can mitigate this problem. This can be a useful + approach to avoid modifying applications that have already bound to + GSS-API, assuming the applications are not statically bound to + specific GSS-API mechanisms. The remainder of this memorandum + defines the thin mechanism: the Low Infrastructure Public Key + Mechanism (LIPKEY). + +2. LIPKEY's Requirements of SPKM + + SPKM-1 with unilateral authentication is close to the desired low + infrastructure model described earlier. This section describes some + additional changes to how SPKM-1 operates in order to realize the low + infrastructure model. These changes include some minor changes in + semantics. While it would be possible to implement these semantic + changes within an SPKM-1 implementation (including using the same + mechanism type Object Identifier (OID) as SPKM-1), the set of changes + stretch the interpretation of RFC 2025 to the point where + compatibility would be in danger. 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 + remainder of this section. + +2.1. Mechanism Type + + SPKM-3 has a different mechanism type OID from SPKM-1. + + 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 defines no required name types of SPKM. LIPKEY requires that + the SPKM-3 implementation support all the mechanism independent name + types in RFC 2078. + + + + + + +Eisler Standards Track [Page 4] + +RFC 2847 LIPKEY June 2000 + + +2.3. Algorithms + +2.3.1. MANDATORY Algorithms + + RFC 2025 defines various algorithms for 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. In + order 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 + + + +Eisler Standards Track [Page 5] + +RFC 2847 LIPKEY June 2000 + + + 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 + + + +Eisler Standards Track [Page 6] + +RFC 2847 LIPKEY June 2000 + + + 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 that 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 SHA-1 algorithm corresponding to id-sha1 is + [FIPS]. + +2.3.2. RECOMMENDED Integrity Algorithms (I-ALG) + + md5WithRSAEncryption + The md5WithRSAEncryption integrity algorithm is listed in + [RFC2025] as mandatory. Due to intellectual property + considerations [RSA-IP], SPKM-3 implementations cannot be + + + +Eisler Standards Track [Page 7] + +RFC 2847 LIPKEY June 2000 + + + 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 that 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 + + + +Eisler Standards Track [Page 8] + +RFC 2847 LIPKEY June 2000 + + + 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. + + + + + + +Eisler Standards Track [Page 9] + +RFC 2847 LIPKEY June 2000 + + +2.5. Quality of Protection (QOP) + + The SPKM-3 initiator and target negotiate the set of algorithms they + mutually support, using the procedure defined 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 + negotiated. + + SPKM breaks the QOP into several fields, as reproduced here 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 enumerate mechanism-defined algorithms. Since this + memorandum introduces a new mechanism, SPKM-3, within the SPKM + family, it is appropriate to add algorithms to the MA subfields of + the respective 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. + + 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 does not recognize MA values for cast5CBC, id-dsa-with-sha1, + HMAC-MD5, or sha1WithRSAEncryption will not select them. + + + +Eisler Standards Track [Page 10] + +RFC 2847 LIPKEY June 2000 + + +3. How LIPKEY Uses SPKM + +3.1. Tokens + + LIPKEY will invoke SPKM-3 to produce SPKM tokens. Since the mechanism + that 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 are + acquired are LIPKEY credentials, a user name and password. How the + user name and password is acquired is dependent upon the operating + environment. A application that invokes GSS_Acquire_cred() while the + application's user has a graphical user interface running might + trigger the appearance of a pop up window that prompts for the + information. A 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 him to invoke a + command that prompts for the information. + + Because the credentials will not 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 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 mapped 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 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. + + + + + + + +Eisler Standards Track [Page 11] + +RFC 2847 LIPKEY June 2000 + + +3.2.3. GSS_Init_sec_context + + When a program invokes GSS_Init_sec_context on the LIPKEY mechanism + type, if 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 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 remainder 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. In this way, + LIPKEY now "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 + do not have provision for specifying anonymous initiators. This is + because SPKM-3 is sufficient for purpose of supporting anonymous + initiators in a low infrastructure environment. + + Clearly, when the LIPKEY caller desires anonymous authentication, + LIPKEY does not add any value, but it is simpler to support the + feature, than to insist the caller directly use SPKM-3. + + + + + + +Eisler Standards Track [Page 12] + +RFC 2847 LIPKEY June 2000 + + + If all goes well, the caller of LIPKEY will be returned a + major_status of GSS_S_CONTINUE_NEEDED via SPKM-3, and 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 in output_context_handle the + LIPKEY context handle, and in mech_type, the LIPKEY mechanism 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, and 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 for a second time. LIPKEY then invokes + the SPKM-3 GSS_Init_sec_context for 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 yet complete, because the initiator must + send to the target the user name and password that were passed to it + via the 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 the claimant_cred_handle refers to (user name + and password), and 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 + + + +Eisler Standards Track [Page 13] + +RFC 2847 LIPKEY June 2000 + + + 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 + this 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 successful (the boolean was TRUE) and + completed LIPKEY context establishment, 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 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. + + + + + + +Eisler Standards Track [Page 14] + +RFC 2847 LIPKEY June 2000 + + +3.3.3. GSS_Accept_sec_context + + When a program invokes GSS_Accept_sec_context on the LIPKEY mechanism + type, if the context handle is NULL, the LIPKEY mechanism will in + turn invoke GSS_Accept_sec_context on an SPKM-3 mechanism implemented + according the requirements described previously. This call to SPKM-3 + is no different than what one would expect for a layered call to + GSS_Accept_sec_context. + + If all goes well, the SPKM-3 GSS_Accept_sec_context call succeeds + with GSS_S_COMPLETE, and the LIPKEY GSS_Accept_sec_context call + returns the output_token to the caller, but with a major_status of + GSS_S_CONTINUE_NEEDED because the LIPKEY initiator is still expected + to send the user name and password. + + Once the SPKM-3 context is in a GSS_S_COMPLETE state, the next token + the target receives will contain the user name and password, wrapped + by the output of an SPKM-3 GSS_Wrap call. The target invokes the + LIPKEY GSS_Accept_sec_context, which in turn invokes the SPKM-3 + GSS_Unwrap routine. The LIPKEY GSS_Accept_sec_context routine then + compares the user name and password with its user name name and + password database. If the initiator's user name and password are + valid, GSS_S_COMPLETE is returned to the caller. Otherwise + GSS_S_FAILURE is returned. In either case, an output_token - equal to + the output_message result from an SPKM-3 GSS_Wrap call on a boolean + value - is returned to the caller. The boolean value is set to TRUE + if the the user name and password were valid, FALSE otherwise. The + target expects no more context establishment tokens from caller. + +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 uses only the mechanism independent name types defined in RFC + 2078. All the name types defined in RFC 2078 are REQUIRED. + + + + + + + + + + +Eisler Standards Track [Page 15] + +RFC 2847 LIPKEY June 2000 + + +4.3. Token Formats + +4.3.1. Context Tokens + + GSS-API defines the context tokens as: + + 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 + initiator. + + + + + + + +Eisler Standards Track [Page 16] + +RFC 2847 LIPKEY June 2000 + + +4.3.1.2.1. From LIPKEY Initiator + + The LIPKEY initiator generates a token that is the 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 does not add any value to GSS_GetMIC and + + + + + +Eisler Standards Track [Page 17] + +RFC 2847 LIPKEY June 2000 + + + GSS_Wrap other than passing the message to the SPKM-3 GSS_GetMIC and + GSS_Wrap, 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 in this approach is in how the target manages the password + after it is done with it. The approach should be safe, provided the + target clears the memory (primary and secondary, such as disk) + buffers that contained the password, and any hash of the password + immediately after it has validated the user's password. + +5.2. Certification Authorities + + The initiator must have a list of trusted Certification Authorities + in order to verify the checksum (rep-ti-integ) on the SPKM-3 target's + context reply token. If it encounters a certificate signed by an + unknown and/or untrusted certificate authority, the initiator MUST + NOT silently accept the certificate. If it does wish to accept the + certificate, it MUST get confirmation from the user running the + application that is using GSS-API. + +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 + + + +Eisler Standards Track [Page 18] + +RFC 2847 LIPKEY June 2000 + + + 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. + +References + + [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. + + + + + +Eisler Standards Track [Page 19] + +RFC 2847 LIPKEY June 2000 + + + [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 places + on-line in 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. + + + + +Eisler Standards Track [Page 20] + +RFC 2847 LIPKEY June 2000 + + + [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 + + The author thanks and acknowledges: + + * 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 + + + + + + + + + + +Eisler Standards Track [Page 21] + +RFC 2847 LIPKEY June 2000 + + +Full Copyright Statement + + 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. + + + + + + + + + + + + + + + + + + + +Eisler Standards Track [Page 22] + -- cgit v1.2.3