rfc2479.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   GSS-API [RFC-2078].

1.1.6.  Channel Bindings

   The concept of channel bindings discussed in GSS-API [RFC-2078] is
   not relevant to the IDUP-GSS-API.

1.2.  IDUP-GSS-API Features and Issues

   This section describes aspects of IDUP-GSS-API operations and of the
   security services which the IDUP-GSS-API provides.  It also provides
   commentary on design issues.

1.2.1.  Status Reporting

   Status reporting in IDUP-GSS-API is to be understood and used as
   described in GSS-API [RFC-2078], with the addition of a number of
   IDUP-specific status codes.  Descriptions of the major_status codes



Adams                        Informational                      [Page 6]

RFC 2479                      IDUP-GSS-API                 December 1998


   used in IDUP are provided in Table 1.  Codes that are informatory
   (i.e., that do not cause the requested operation to fail) are
   indicated with the symbol "(I)".

   As with GSS-API, minor_status codes, which provide more detailed
   status information than major_status codes, and which may include
   status codes specific to the underlying security mechanism, are not
   specified in this document.

    Table 1: IDUP-GSS-API Major Status Codes

      GSS_S_BAD_MECH indicates that a mech_type unsupported by the
      IDUP_GSS-API implementation was requested, causing the environment
      establishment operation to fail.

      GSS_S_BAD_QOP indicates that the provided qop_alg value is not
      recognized or supported for the environment.

      GSS_S_BAD_MIC indicates that the received P-IDU contains an
      incorrect integrity field (e.g., signature or MAC) for the data.

      GSS_S_COMPLETE indicates that the requested operation was
      successful.

      GSS_S_CREDENTIALS_EXPIRED indicates that the credentials
      associated with this operation have expired, so that the requested
      operation cannot be performed.

      GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks
      performed on the credential structure referenced by
      claimant_cred_handle failed, preventing further processing from
      being performed using that credential structure.

      GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed
      on the received P-IDU failed, preventing further processing from
      being performed.

      GSS_S_FAILURE indicates that the requested operation could not be
      accomplished for reasons unspecified at the IDUP-GSS-API level,
      and that no interface-defined recovery action is available.

      GSS_S_NO_CRED indicates that no environment was established,
      either because the input cred_handle was invalid or because the
      caller lacks authorization to access the referenced credentials.

      IDUP_S_BAD_DOA_KEY indicates that the key used to provide IDU data
      origin auth. / integ. has either expired or been revoked.




Adams                        Informational                      [Page 7]

RFC 2479                      IDUP-GSS-API                 December 1998


      IDUP_S_BAD_ENC_IDU indicates that decryption of the received IDU
      cannot be completed because the encrypted IDU was
      invalid/defective (e.g., the final block was short or had
      incorrect padding).

      IDUP_S_BAD_KE_KEY indicates that the key used to establish a key
      for confidentiality purposes between originator and target has
      either expired or been revoked.

      IDUP_S_BAD_TARG_INFO indicates that the full set of supplied
      information regarding the target(s) is invalid or is insufficient
      for the protection of an IDU, so P-IDU cannot be created.

      IDUP_S_DEFECTIVE_VERIF indicates that consistency checks performed
      on Service_Verification_Info failed, preventing further processing
      from being performed with that parameter.

      IDUP_S_ENCAPSULATION_UNAVAIL (I) indicates that the underlying
      mechanism does not support encapsulation of the M-IDU into the
      token.

      IDUP_S_INAPPROPRIATE_CRED indicates that the credentials supplied
      do not contain the information necessary for P-IDU unprotection.

      IDUP_S_INCOMPLETE (I) indicates that the unprotection of the P-IDU
      is not yet complete (i.e., a determination cannot yet be made on
      the validity of the P-IDU).  The application should call
      IDUP_Form_Complete_PIDU and then should call this function again
      with the complete P-IDU.

      IDUP_S_INCONSISTENT_PARAMS indicates that the supplied parameters
      are inconsistent (e.g., only one or the other of two parameters
      may be supplied, but both have been input).

      IDUP_S_MORE_OUTBUFFER_NEEDED (I) indicates that the output buffer
      supplied is too small to hold the generated data.  The application
      should continue calling this routine (until GSS_S_COMPLETE is
      returned) in order to get all remaining output data.

      IDUP_S_MORE_PIDU_NEEDED (I) indicates that not enough of the P-IDU
      has been input yet for the completion of StartUnprotect.  The
      application should call this routine again with another buffer of
      P-IDU in partial(initial)_pidu_buffer.

      IDUP_S_NO_ENV indicates that no valid environment was recognized
      for the env_handle provided.





Adams                        Informational                      [Page 8]

RFC 2479                      IDUP-GSS-API                 December 1998


      IDUP_S_NO_MATCH indicates that Service_Verification_Info (or
      evidence_check) and the P-IDU to be verified do not match.

      IDUP_S_REQ_TIME_SERVICE_UNAVAIL indicates that the time service
      requested (TTIME or UTIME) is not available in the environment.

      IDUP_S_SERVICE_UNAVAIL indicates that the underlying mechanism
      does not support the service requested.

      IDUP_S_SERV_VERIF_INFO_NEEDED (I) indicates that the
      Service_Verification_Info parameter bundle must be input in order
      for service verification to proceed.  The output parameter
      service_verification_info_id contains an identifier which may be
      used by the calling application to locate the necessary
      information.

      IDUP_S_UNKNOWN_OPER_ID indicates that the input prot_oper_id value
      is not recognized or supported in the underlying mechanism.

1.2.2. Per-IDU Security Service Availability

   Per-IDU security service availability in IDUP-GSS-API is to be
   understood and used as described in GSS-API [RFC-2078], with the
   exception that combinations of services requested by the calling
   application and supported by the underlying mechanism may be applied
   simultaneously to any IDU (true for both the SE and the EV calls, but
   true in the fullest sense for the GP calls).

   GSS-API callers desiring per-message security services should check
   the relevant service OBJECT IDs at environment establishment time to
   ensure that what is available in the established environment is
   suitable for their security needs.

1.2.3. Per-IDU Replay Detection and Sequencing

   The concept of per-IDU replay detection and sequencing discussed in
   GSS-API [RFC-2078] is not relevant to the IDUP-GSS-API.

1.2.4.  Quality of Protection

   The concept of QOP control in IDUP-GSS-API is to be understood
   essentially as described in GSS-API [RFC-2078].  However, the actual
   description and use of the QOP parameter is given as follows.

   The qop_algs parameter for IDUP is defined to be a 32-bit unsigned
   integer with the following bit-field assignments:





Adams                        Informational                      [Page 9]

RFC 2479                      IDUP-GSS-API                 December 1998


            31 (MSB)                               (LSB) 0
            ----------------------------------------------
            |        U(19)       | TS(5) | IA(4) | MA(4) |
            ----------------------------------------------

   where

      U is a 19-bit Unspecified field (available for future
      use/expansion) -- must be set to zero;

      TS is a 5-bit Type Specifier (a semantic qualifier whose value
      specifies the type of algorithm which may be used to protect the
      corresponding IDU -- see below for details);

      IA is a 4-bit field enumerating Implementation-specific
      Algorithms; and

      MA is a 4-bit field enumerating Mechanism-defined Algorithms.

   The interpretation of the qop_algs parameter is as follows.  The MA
   field is examined first.  If it is non-zero then the algorithm used
   to protect the IDU is the mechanism-specified algorithm corresponding
   to that integer value.

   If MA is zero then IA is examined.  If this field value is non-zero
   then the algorithm used to protect the IDU is the implementation-
   specified algorithm corresponding to that integer value.  Note that
   use of this field may hinder portability since a particular value may
   specify one algorithm in one implementation of the mechanism and may
   not be supported or may specify a completely different algorithm in
   another implementation of the mechanism.

   Finally, if both MA and IA are zero then TS is examined.  A value of
   zero for TS specifies the default algorithm for the established
   mechanism.  A non-zero value for TS corresponds to a particular
   algorithm qualifier and selects any algorithm from the mechanism
   specification which satisfies that qualifier (which actual algorithm
   is selected is an implementation choice; the calling application need
   not be aware of the choice made).

   The following TS values (i.e., algorithm qualifiers) are specified;
   other values may be added in the future.









Adams                        Informational                     [Page 10]

RFC 2479                      IDUP-GSS-API                 December 1998


   When qop_algs is used to select a confidentiality algorithm:

      00000  (0) = default confidentiality algorithm
      00001  (1) = IDUP_SYM_ALG_STRENGTH_STRONG
      00010  (2) = IDUP_SYM_ALG_STRENGTH_MEDIUM
      00011  (3) = IDUP_SYM_ALG_STRENGTH_WEAK
      11111 (31) = IDUP_NO_CONFIDENTIALITY

   When qop_algs is used to select a DOA/integrity algorithm:

      00000  (0) = default integrity algorithm
      00001  (1) = IDUP_INT_ALG_DIG_SIGNATURE
                   (integrity provided through a digital signature)
      00010  (2) = IDUP_INT_ALG_NON_DIG_SIGNATURE
                   (integrity without a dig. sig. (e.g., with a MAC))
      11111 (31) = IDUP_NO_INTEGRITY

   Clearly, qualifiers such as strong, medium, and weak are debatable
   and likely to change with time, but for the purposes of this version
   of the specification we define these terms as follows.  A
   confidentiality algorithm is "weak" if the effective key length of
   the cipher is 40 bits or less; it is "medium-strength" if the
   effective key length is strictly between 40 and 80 bits; and it is
   "strong" if the effective key length is 80 bits or greater.
   ("Effective key length" describes the computational effort required
   to break a cipher using the best-known cryptanalytic attack against
   that cipher.)

   A five-bit TS field allows up to 30 qualifiers for each of
   confidentiality and integrity (since "0" is reserved for "default"
   and "31" is reserved for "none", as shown above).  This document
   specifies three for confidentiality and two for integrity, leaving a
   lot of room for future specification.  Suggestions of qualifiers such
   as "fast", "medium-speed", and "slow" have been made, but such terms
   are difficult to quantify (and in any case are platform- and
   processor-dependent), and so have been left out of this initial
   specification.  The intention is that the TS terms be quantitative,
   environment-independent qualifiers of algorithms, as much as this is
   possible.

   Use of the qop_algs parameter as defined above is ultimately meant to
   be as follows.

    - TS values are specified at the IDUP-GSS-API level and are
      therefore portable across mechanisms.  Applications which know
      nothing about algorithms are still able to choose "quality" of
      protection for their message tokens.




Adams                        Informational                     [Page 11]

RFC 2479                      IDUP-GSS-API                 December 1998


    - MA values are specified at the mechanism level and are therefore
      portable across implementations of a mechanism.

    - IA values are specified at the implementation level (in user
      documentation, for example) and are therefore typically non-
      portable.  An application which is aware of its own mechanism
      implementation and the mechanism implementation of its intended
      P-IDU recipient, however, is free to use these values since they
      will be perfectly valid and meaningful for protecting IDUs between
      those entities.