The Kerberos Version 5 GSS-API Mechanism
RFC 1964

Document Type RFC - Proposed Standard (June 1996; No errata)
Updated by RFC 4121, RFC 6649
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1964 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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 {
Show full document text