rfc2847.txt

RFC 的详细文档！


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: