rfc1964.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/4 页

Network Working Group                                            J. Linn
Request for Comments: 1964                       OpenVision Technologies
Category: Standards Track                                      June 1996


                The Kerberos Version 5 GSS-API Mechanism

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.

ABSTRACT

   This specification defines protocols, procedures, and conventions to
   be employed by peers implementing the Generic Security Service
   Application Program Interface (as specified in RFCs 1508 and 1509)
   when using Kerberos Version 5 technology (as specified in RFC 1510).

ACKNOWLEDGMENTS

   Much of the material in this memo is based on working documents
   drafted by John Wray of Digital Equipment Corporation and on
   discussions, implementation activities, and interoperability testing
   involving Marc Horowitz, Ted Ts'o, and John Wray.  Particular thanks
   are due to each of these individuals for their contributions towards
   development and availability of GSS-API support within the Kerberos
   Version 5 code base.

1. Token Formats

   This section discusses protocol-visible characteristics of the GSS-
   API mechanism to be implemented atop Kerberos V5 security technology
   per RFC-1508 and RFC-1510; it defines elements of protocol for
   interoperability and is independent of language bindings per RFC-
   1509.

   Tokens transferred between GSS-API peers (for security context
   management and per-message protection purposes) are defined.  The
   data elements exchanged between a GSS-API endpoint implementation and
   the Kerberos KDC are not specific to GSS-API usage and are therefore
   defined within RFC-1510 rather than within this specification.






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


   To support ongoing experimentation, testing, and evolution of the
   specification, the Kerberos V5 GSS-API mechanism as defined in this
   and any successor memos will be identified with the following Object
   Identifier, as defined in RFC-1510, until the specification is
   advanced to the level of Proposed Standard RFC:

   {iso(1), org(3), dod(5), internet(1), security(5), kerberosv5(2)}

   Upon advancement to the level of Proposed Standard RFC, the Kerberos
   V5 GSS-API mechanism will be identified by an Object Identifier
   having the value:

   {iso(1) member-body(2) United States(840) mit(113554) infosys(1)
   gssapi(2) krb5(2)}

1.1. Context Establishment Tokens

   Per RFC-1508, Appendix B, the initial context establishment token
   will be enclosed within framing as follows:

   InitialContextToken ::=
   [APPLICATION 0] IMPLICIT SEQUENCE {
           thisMech        MechType
                   -- MechType is OBJECT IDENTIFIER
                   -- representing "Kerberos V5"
           innerContextToken ANY DEFINED BY thisMech
                   -- contents mechanism-specific;
                   -- ASN.1 usage within innerContextToken
                   -- is not required
           }

   The innerContextToken of the initial context token will consist of a
   Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-id
   (TOK_ID) field, which shall contain the value 01 00.

   The above GSS-API framing shall be applied to all tokens emitted by
   the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR,
   context-deletion, and per-message tokens, not just to the initial
   token in a context establishment sequence.  While not required by
   RFC-1508, this enables implementations to perform enhanced error-
   checking. The innerContextToken field of context establishment tokens
   for the Kerberos V5 GSS-API mechanism will contain a Kerberos message
   (KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_ID
   field containing 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_REP
   messages and 03 00 for KRB_ERROR messages.






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


1.1.1. Initial Token

   Relevant KRB_AP_REQ syntax (from RFC-1510) is as follows:

   AP-REQ ::= [APPLICATION 14] SEQUENCE {
           pvno [0]        INTEGER,        -- indicates Version 5
           msg-type [1]    INTEGER,        -- indicates KRB_AP_REQ
           ap-options[2]   APOptions,
           ticket[3]       Ticket,
           authenticator[4]        EncryptedData
   }

   APOptions ::= BIT STRING {
           reserved (0),
           use-session-key (1),
           mutual-required (2)
   }

   Ticket ::= [APPLICATION 1] SEQUENCE {
           tkt-vno [0]     INTEGER,        -- indicates Version 5
           realm [1]       Realm,
           sname [2]       PrincipalName,
           enc-part [3]    EncryptedData
   }

   -- Encrypted part of ticket
   EncTicketPart ::= [APPLICATION 3] SEQUENCE {
           flags[0]        TicketFlags,
           key[1]          EncryptionKey,
           crealm[2]       Realm,
           cname[3]        PrincipalName,
           transited[4]    TransitedEncoding,
           authtime[5]     KerberosTime,
           starttime[6]    KerberosTime OPTIONAL,
           endtime[7]      KerberosTime,
           renew-till[8]   KerberosTime OPTIONAL,
           caddr[9]        HostAddresses OPTIONAL,
           authorization-data[10]  AuthorizationData OPTIONAL
   }

   -- Unencrypted authenticator
   Authenticator ::= [APPLICATION 2] SEQUENCE  {
           authenticator-vno[0]    INTEGER,
           crealm[1]               Realm,
           cname[2]                PrincipalName,
           cksum[3]                Checksum OPTIONAL,
           cusec[4]                INTEGER,
           ctime[5]                KerberosTime,



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


           subkey[6]               EncryptionKey OPTIONAL,
           seq-number[7]           INTEGER OPTIONAL,
           authorization-data[8]   AuthorizationData OPTIONAL
   }

   For purposes of this specification, the authenticator shall include
   the optional sequence number, and the checksum field shall be used to
   convey channel binding, service flags, and optional delegation
   information.  The checksum will have a type of 0x8003 (a value being
   registered within the Kerberos protocol specification), and a value
   field of at least 24 bytes in length.  The length of the value field
   is extended beyond 24 bytes if and only if an optional facility to
   carry a Kerberos-defined KRB_CRED message for delegation purposes is
   supported by an implementation and active on a context. When
   delegation is active, a TGT with its FORWARDABLE flag set will be
   transferred within the KRB_CRED message.

   The checksum value field's format is as follows:

   Byte    Name    Description
   0..3    Lgth    Number of bytes in Bnd field;
                   Currently contains hex 10 00 00 00
                   (16, represented in little-endian form)
   4..19   Bnd     MD5 hash of channel bindings, taken over all non-null
                   components of bindings, in order of declaration.
                   Integer fields within channel bindings are represented
                   in little-endian order for the purposes of the MD5
                   calculation.
   20..23  Flags   Bit vector of context-establishment flags,
                   with values consistent with RFC-1509, p. 41:
                           GSS_C_DELEG_FLAG:       1
                           GSS_C_MUTUAL_FLAG:      2
                           GSS_C_REPLAY_FLAG:      4
                           GSS_C_SEQUENCE_FLAG:    8
                           GSS_C_CONF_FLAG:        16
                           GSS_C_INTEG_FLAG:       32
                   The resulting bit vector is encoded into bytes 20..23
                   in little-endian form.
   24..25  DlgOpt  The Delegation Option identifier (=1) [optional]
   26..27  Dlgth   The length of the Deleg field. [optional]
   28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional]

   In computing the contents of the "Bnd" field, the following detailed
   points apply:

        (1) Each integer field shall be formatted into four bytes, using
        little-endian byte ordering, for purposes of MD5 hash
        computation.



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


        (2) All input length fields within gss_buffer_desc elements of a
        gss_channel_bindings_struct, even those which are zero-valued,
        shall be included in the hash calculation; the value elements of
        gss_buffer_desc elements shall be dereferenced, and the
        resulting data shall be included within the hash computation,
        only for the case of gss_buffer_desc elements having non-zero
        length specifiers.

        (3) If the caller passes the value GSS_C_NO_BINDINGS instead of
        a valid channel bindings structure, the Bnd field shall be set
        to 16 zero-valued bytes.

   In the initial Kerberos V5 GSS-API mechanism token (KRB_AP_REQ token)
   from initiator to target, the GSS_C_DELEG_FLAG, GSS_C_MUTUAL_FLAG,
   GSS_C_REPLAY_FLAG, and GSS_C_SEQUENCE_FLAG values shall each be set
   as the logical AND of the initiator's corresponding request flag to
   GSS_Init_sec_context() and a Boolean indicator of whether that
   optional service is available to GSS_Init_sec_context()'s caller.
   GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG, for which no corresponding
   context-level input indicator flags to GSS_Init_sec_context() exist,
   shall each be set to indicate whether their respective per-message
   protection services are available for use on the context being
   established.

   When input source address channel binding values are provided by a
   caller (i.e., unless the input argument is GSS_C_NO_BINDINGS or the
   source address specifier value within the input structure is
   GSS_C_NULL_ADDRTYPE), and the corresponding token received from the
   context's peer bears address restrictions, it is recommended that an
   implementation of the Kerberos V5 GSS-API mechanism should check that
   the source address as provided by the caller matches that in the
   received token, and should return the GSS_S_BAD_BINDINGS major_status
   value if a mismatch is detected. Note: discussion is ongoing about
   the strength of recommendation to be made in this area, and on the
   circumstances under which such a recommendation should be applicable;
   implementors are therefore advised that changes on this matter may be
   included in subsequent versions of this specification.

1.1.2. Response Tokens

   A context establishment sequence based on the Kerberos V5 mechanism
   will perform one-way authentication (without confirmation or any
   return token from target to initiator in response to the initiator's
   KRB_AP_REQ) if the mutual_req bit is not set in the application's
   call to GSS_Init_sec_context().  Applications requiring confirmation
   that their authentication was successful should request mutual
   authentication, resulting in a "mutual-required" indication within
   KRB_AP_REQ APoptions and the setting of the mutual_req bit in the