    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]