rfc1964.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,124 行 · 第 1/4 页

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   Its interpretation is OS-specific.  This name form is constructed as:

      username

   Assuming that users' principal names are the same as their local
   operating system names, an implementation of GSS_Import_name() based
   on Kerberos V5 technology can process names of this form by
   postfixing an "@" sign and the name of the local realm.

2.2.2. Machine UID Form

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) machine_uid_name(2)}.  The recommended symbolic name for
   this type is "GSS_KRB5_NT_MACHINE_UID_NAME".

   This name type is used to indicate a numeric user identifier
   corresponding to a user on a local system.  Its interpretation is
   OS-specific.  The gss_buffer_desc representing a name of this type
   should contain a locally-significant uid_t, represented in host byte
   order.  The GSS_Import_name() operation resolves this uid into a
   username, which is then treated as the User Name Form.

2.2.3. String UID Form

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) string_uid_name(3)}.  The recommended symbolic name for
   this type is "GSS_KRB5_NT_STRING_UID_NAME".

   This name type is used to indicate a string of digits representing
   the numeric user identifier of a user on a local system.  Its
   interpretation is OS-specific. This name type is similar to the
   Machine UID Form, except that the buffer contains a string
   representing the uid_t.

3. Credentials Management

   The Kerberos V5 protocol uses different credentials (in the GSSAPI
   sense) for initiating and accepting security contexts.  Normal
   clients receive a ticket-granting ticket (TGT) and an associated
   session key at "login" time; the pair of a TGT and its corresponding
   session key forms a credential which is suitable for initiating
   security contexts.  A ticket-granting ticket, its session key, and
   any other (ticket, key) pairs obtained through use of the ticket-
   granting-ticket, are typically stored in a Kerberos V5 credentials
   cache, sometimes known as a ticket file.




Linn                        Standards Track                    [Page 16]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   The encryption key used by the Kerberos server to seal tickets for a
   particular application service forms the credentials suitable for
   accepting security contexts.  These service keys are typically stored
   in a Kerberos V5 key table, or srvtab file.  In addition to their use
   as accepting credentials, these service keys may also be used to
   obtain initiating credentials for their service principal.

   The Kerberos V5 mechanism's credential handle may contain references
   to either or both types of credentials.  It is a local matter how the
   Kerberos V5 mechanism implementation finds the appropriate Kerberos
   V5 credentials cache or key table.

   However, when the Kerberos V5 mechanism attempts to obtain initiating
   credentials for a service principal which are not available in a
   credentials cache, and the key for that service principal is
   available in a Kerberos V5 key table, the mechanism should use the
   service key to obtain initiating credentials for that service.  This
   should be accomplished by requesting a ticket-granting-ticket from
   the Kerberos Key Distribution Center (KDC), and decrypting the KDC's
   reply using the service key.

4. Parameter Definitions

   This section defines parameter values used by the Kerberos V5 GSS-API
   mechanism.  It defines interface elements in support of portability,
   and assumes use of C language bindings per RFC-1509.

4.1. Minor Status Codes

   This section recommends common symbolic names for minor_status values
   to be returned by the Kerberos V5 GSS-API mechanism.  Use of these
   definitions will enable independent implementors to enhance
   application portability across different implementations of the
   mechanism defined in this specification.  (In all cases,
   implementations of GSS_Display_status() will enable callers to
   convert minor_status indicators to text representations.) Each
   implementation should make available, through include files or other
   means, a facility to translate these symbolic names into the concrete
   values which a particular GSS-API implementation uses to represent
   the minor_status values specified in this section.

   It is recognized that this list may grow over time, and that the need
   for additional minor_status codes specific to particular
   implementations may arise.  It is recommended, however, that
   implementations should return a minor_status value as defined on a
   mechanism-wide basis within this section when that code is accurately
   representative of reportable status rather than using a separate,
   implementation-defined code.



Linn                        Standards Track                    [Page 17]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


4.1.1. Non-Kerberos-specific codes

   GSS_KRB5_S_G_BAD_SERVICE_NAME
           /* "No @ in SERVICE-NAME name string" */
   GSS_KRB5_S_G_BAD_STRING_UID
           /* "STRING-UID-NAME contains nondigits" */
   GSS_KRB5_S_G_NOUSER
           /* "UID does not resolve to username" */
   GSS_KRB5_S_G_VALIDATE_FAILED
           /* "Validation error" */
   GSS_KRB5_S_G_BUFFER_ALLOC
           /* "Couldn't allocate gss_buffer_t data" */
   GSS_KRB5_S_G_BAD_MSG_CTX
           /* "Message context invalid" */
   GSS_KRB5_S_G_WRONG_SIZE
           /* "Buffer is the wrong size" */
   GSS_KRB5_S_G_BAD_USAGE
           /* "Credential usage type is unknown" */
   GSS_KRB5_S_G_UNKNOWN_QOP
           /* "Unknown quality of protection specified" */

4.1.2. Kerberos-specific-codes

   GSS_KRB5_S_KG_CCACHE_NOMATCH
           /* "Principal in credential cache does not match desired name" */
   GSS_KRB5_S_KG_KEYTAB_NOMATCH
           /* "No principal in keytab matches desired name" */
   GSS_KRB5_S_KG_TGT_MISSING
           /* "Credential cache has no TGT" */
   GSS_KRB5_S_KG_NO_SUBKEY
           /* "Authenticator has no subkey" */
   GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
           /* "Context is already fully established" */
   GSS_KRB5_S_KG_BAD_SIGN_TYPE
           /* "Unknown signature type in token" */
   GSS_KRB5_S_KG_BAD_LENGTH
           /* "Invalid field length in token" */
   GSS_KRB5_S_KG_CTX_INCOMPLETE
           /* "Attempt to use incomplete security context" */

4.2. Quality of Protection Values

   This section defines Quality of Protection (QOP) values to be used
   with the Kerberos V5 GSS-API mechanism as input to GSS_Wrap() and
   GSS_GetMIC() routines in order to select among alternate integrity
   and confidentiality algorithms. Additional QOP values may be added in
   future versions of this specification.  Non-overlapping bit positions
   are and will be employed in order that both integrity and



Linn                        Standards Track                    [Page 18]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   confidentiality QOP may be selected within a single parameter, via
   inclusive-OR of the specified integrity and confidentiality values.

4.2.1. Integrity Algorithms

   The following Quality of Protection (QOP) values are currently
   defined for the Kerberos V5 GSS-API mechanism, and are used to select
   among alternate integrity checking algorithms.

   GSS_KRB5_INTEG_C_QOP_MD5        (numeric value: 1)
           /* Integrity using partial MD5 ("MD2.5") of plaintext */

   GSS_KRB5_INTEG_C_QOP_DES_MD5    (numeric value: 2)
           /* Integrity using DES MAC of MD5 of plaintext */

   GSS_KRB5_INTEG_C_QOP_DES_MAC    (numeric value: 3)
           /* Integrity using DES MAC of plaintext */

4.2.2. Confidentiality Algorithms

   Only one confidentiality QOP value is currently defined for the
   Kerberos V5 GSS-API mechanism:

   GSS_KRB5_CONF_C_QOP_DES         (numeric value: 0)
           /* Confidentiality with DES */

   Note: confidentiality QOP should be indicated only by GSS-API calls
   capable of providing confidentiality services. If non-zero
   confidentiality QOP values are defined in future to represent
   different algorithms, therefore, the bit positions containing those
   values should be cleared before being returned by implementations of
   GSS_GetMIC() and GSS_VerifyMIC().

4.3. Buffer Sizes

   All implementations of this specification shall be capable of
   accepting buffers of at least 16 Kbytes as input to GSS_GetMIC(),
   GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting
   the output_token generated by GSS_Wrap() for a 16 Kbyte input buffer
   as input to GSS_Unwrap(). Support for larger buffer sizes is optional
   but recommended.










Linn                        Standards Track                    [Page 19]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


5. Security Considerations

   Security issues are discussed throughout this memo.

6. References


   [RFC-1321]: Rivest, R., "The MD5 Message-Digest Algorithm", RFC
   1321, April 1992.

   [RFC-1508]: Linn, J., "Generic Security Service Application Program
   Interface", RFC 1508, September 1993.

   [RFC-1509]: Wray, J., "Generic Security Service Application Program
   Interface: C-bindings", RFC 1509, September 1993.

   [RFC-1510]: Kohl, J., and C. Neuman, "The Kerberos Network
   Authentication Service (V5)", RFC 1510, September 1993.

   [FIPS-PUB-113]: National Bureau of Standards, Federal Information
   Processing Standard 113, "Computer Data Authentication", May 1985.

AUTHOR'S ADDRESS

   John Linn
   OpenVision Technologies
   One Main St.
   Cambridge, MA  02142  USA

   Phone: [phone]
   EMail: [e-mail]




















Linn                        Standards Track                    [Page 20]