rfc1964.txt

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


RFC 1964               Kerberos Version 5 GSS-API              June 1996


   DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the
   plaintext padded data per [FIPS-PUB-113], employing the context key
   and a zero IV. The plaintext padded data is already assured to be an
   integral multiple of 8 bytes; no additional padding is required or
   applied in order to accomplish MAC calculation.  The result is an 8-
   byte value, which is stored in the SGN_CKSUM field.  Support for this
   lgorithm may not be present in all implementations.

1.2.2.2. Sequence Number

   Sequence number field: The 8 byte plaintext sequence number field is
   formed from the sender's four-byte sequence number as follows.  If
   the four bytes of the sender's sequence number are named s0, s1, s2
   and s3 (from least to most significant), the plaintext sequence
   number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
   di), where 'di' is the direction-indicator (Hex 0 - sender is the
   context initiator, Hex FF - sender is the context acceptor).

   The field is then DES-CBC encrypted using the context key and an IV
   formed from the first 8 bytes of the SEAL_CKSUM field.

   After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's
   sequence numbers are incremented by one.

1.2.2.3. Padding

   Data padding: Before encryption and/or signature calculation,
   plaintext data is padded to the next highest multiple of 8 bytes, by
   appending between 1 and 8 bytes, the value of each such byte being
   the total number of pad bytes.  For example, given data of length 20
   bytes, four pad bytes will be appended, and each byte will contain
   the hex value 04.  An 8-byte random confounder is prepended to the
   data, and signatures are calculated over the resulting padded
   plaintext.

   After padding, the data is encrypted according to the algorithm
   specified in the SEAL_ALG field.  For SEAL_ALG=DES (the only non-null
   algorithm currently supported), the data is encrypted using DES-CBC,
   with an IV of zero.  The key used is derived from the established
   context key by XOR-ing the context key with the hexadecimal constant
   f0f0f0f0f0f0f0f0.

1.2.3. Context deletion token

   The token emitted by GSS_Delete_sec_context() is based on the packet
   format for tokens emitted by GSS_GetMIC().  The context-deletion
   token has the following format:




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


   Byte no          Name           Description
    0..1           TOK_ID          Identification field.
                                   Tokens emitted by
                                   GSS_Delete_sec_context() contain
                                   the hex value 01 02 in this field.
    2..3           SGN_ALG         Integrity algorithm indicator.
                                   00 00 - DES MAC MD5
                                   01 00 - MD2.5
                                   02 00 - DES MAC
    4..7           Filler          Contains ff ff ff ff
    8..15          SND_SEQ         Sequence number field.
    16..23         SGN_CKSUM       Checksum of "to-be-signed data",
                                   calculated according to algorithm
                                   specified in SGN_ALG field.

   SGN_ALG and SND_SEQ will be calculated as for tokens emitted by
   GSS_GetMIC().  The SGN_CKSUM will be calculated as for tokens emitted
   by GSS_GetMIC(), except that the user-data component of the "to-be-
   signed" data will be a zero-length string.

2. Name Types and Object Identifiers

   This section discusses the name types which may be passed as input to
   the Kerberos V5 GSS-API mechanism's GSS_Import_name() call, and their
   associated identifier values.  It defines interface elements in
   support of portability, and assumes use of C language bindings per
   RFC-1509.  In addition to specifying OID values for name type
   identifiers, symbolic names are included and recommended to GSS-API
   implementors in the interests of convenience to callers.  It is
   understood that not all implementations of the Kerberos V5 GSS-API
   mechanism need support all name types in this list, and that
   additional name forms will likely be added to this list over time.
   Further, the definitions of some or all name types may later migrate
   to other, mechanism-independent, specifications. The occurrence of a
   name type in this specification is specifically not intended to
   suggest that the type may be supported only by an implementation of
   the Kerberos V5 mechanism.   In particular, the occurrence of the
   string "_KRB5_" in the symbolic name strings constitutes a means to
   unambiguously register the name strings, avoiding collision with
   other documents; it is not meant to limit the name types' usage or
   applicability.

   For purposes of clarification to GSS-API implementors, this section's
   discussion of some name forms describes means through which those
   forms can be supported with existing Kerberos technology.  These
   discussions are not intended to preclude alternative implementation
   strategies for support of the name forms within Kerberos mechanisms
   or mechanisms based on other technologies.  To enhance application



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


   portability, implementors of mechanisms are encouraged to support
   name forms as defined in this section, even if their mechanisms are
   independent of Kerberos V5.

2.1. Mandatory Name Forms

   This section discusses name forms which are to be supported by all
   conformant implementations of the Kerberos V5 GSS-API mechanism.

2.1.1. Kerberos Principal Name 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)
   krb5(2) krb5_name(1)}.  The recommended symbolic name for this type
   is "GSS_KRB5_NT_PRINCIPAL_NAME".

   This name type corresponds to the single-string representation of a
   Kerberos name.  (Within the MIT Kerberos V5 implementation, such
   names are parseable with the krb5_parse_name() function.)  The
   elements included within this name representation are as follows,
   proceeding from the beginning of the string:

        (1) One or more principal name components; if more than one
        principal name component is included, the components are
        separated by `/`.  Arbitrary octets may be included within
        principal name components, with the following constraints and
        special considerations:

           (1a) Any occurrence of the characters `@` or `/` within a
           name component must be immediately preceded by the `\`
           quoting character, to prevent interpretation as a component
           or realm separator.

           (1b) The ASCII newline, tab, backspace, and null characters
           may occur directly within the component or may be
           represented, respectively, by `\n`, `\t`, `\b`, or `\0`.

           (1c) If the `\` quoting character occurs outside the contexts
           described in (1a) and (1b) above, the following character is
           interpreted literally.  As a special case, this allows the
           doubled representation `\\` to represent a single occurrence
           of the quoting character.

           (1d) An occurrence of the `\` quoting character as the last
           character of a component is illegal.






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


        (2) Optionally, a `@` character, signifying that a realm name
        immediately follows. If no realm name element is included, the
        local realm name is assumed.  The `/` , `:`, and null characters
        may not occur within a realm name; the `@`, newline, tab, and
        backspace characters may be included using the quoting
        conventions described in (1a), (1b), and (1c) above.

2.1.2. Host-Based Service Name Form

   This name form has been incorporated at the mechanism-independent
   GSS-API level as of GSS-API, Version 2.  This subsection retains the
   Object Identifier and symbolic name assignments previously made at
   the Kerberos V5 GSS-API mechanism level, and adopts the definition as
   promoted to the mechanism-independent level.

   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) service_name(4)}.  The previously recommended symbolic
   name for this type is "GSS_KRB5_NT_HOSTBASED_SERVICE_NAME".  The
   currently preferred symbolic name for this type is
   "GSS_C_NT_HOSTBASED_SERVICE".

   This name type is used to represent services associated with host
   computers.  This name form is constructed using two elements,
   "service" and "hostname", as follows:

      service@hostname

   When a reference to a name of this type is resolved, the "hostname"
   is canonicalized by attempting a DNS lookup and using the fully-
   qualified domain name which is returned, or by using the "hostname"
   as provided if the DNS lookup fails.  The canonicalization operation
   also maps the host's name into lower-case characters.

   The "hostname" element may be omitted. If no "@" separator is
   included, the entire name is interpreted as the service specifier,
   with the "hostname" defaulted to the canonicalized name of the local
   host.

   Values for the "service" element will be registered with the IANA.

2.1.3. Exported Name Object Form for Kerberos V5 Mechanism

   Support for this name form is not required for GSS-V1
   implementations, but will be required for use in conjunction with the
   GSS_Export_name() call planned for GSS-API Version 2.  Use of this
   name form will be signified by a "GSS-API Exported Name Object" OID
   value which will be defined at the mechanism-independent level for



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


   GSS-API Version 2.

   This name type represents a self-describing object, whose framing
   structure will be defined at the mechanism-independent level for
   GSS-API Version 2.  When generated by the Kerberos V5 mechanism, the
   Mechanism OID within the exportable name shall be that of the
   Kerberos V5 mechanism.  The name component within the exportable name
   shall be a contiguous string with structure as defined for the
   Kerberos Principal Name Form.

   In order to achieve a distinguished encoding for comparison purposes,
   the following additional constraints are imposed on the export
   operation:

        (1) all occurrences of the characters `@`,  `/`, and `\` within
        principal components or realm names shall be quoted with an
        immediately-preceding `\`.

        (2) all occurrences of the null, backspace, tab, or newline
        characters within principal components or realm names will be
        represented, respectively, with `\0`, `\b`, `\t`, or `\n`.

        (3) the `\` quoting character shall not be emitted within an
        exported name except to accomodate cases (1) and (2).

2.2. Optional Name Forms

   This section discusses additional name forms which may optionally be
   supported by implementations of the Kerberos V5 GSS-API mechanism.
   It is recognized that some of the name forms cited here are derived
   from UNIX(tm) operating system platforms; some listed forms may be
   irrelevant to non-UNIX platforms, and definition of additional forms
   corresponding to such platforms may also be appropriate.  It is also
   recognized that OS-specific functions outside GSS-API are likely to
   exist in order to perform translations among these forms, and that
   GSS-API implementations supporting these forms may themselves be
   layered atop such OS-specific functions.  Inclusion of this support
   within GSS-API implementations is intended as a convenience to
   applications.

2.2.1. User Name 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) user_name(1)}.  The recommended symbolic name for this
   type is "GSS_KRB5_NT_USER_NAME".

   This name type is used to indicate a named user on a local system.



Linn                        Standards Track                    [Page 15]