tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4120

 
 
 

The Kerberos Network Authentication Service (V5)

Part 4 of 6, p. 73 to 100
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 73 
5.4.  Specifications for the AS and TGS Exchanges

   This section specifies the format of the messages used in the
   exchange between the client and the Kerberos server.  The format of
   possible error messages appears in Section 5.9.1.

5.4.1.  KRB_KDC_REQ Definition

   The KRB_KDC_REQ message has no application tag number of its own.
   Instead, it is incorporated into either KRB_AS_REQ or KRB_TGS_REQ,
   each of which has an application tag, depending on whether the
   request is for an initial ticket or an additional ticket.  In either
   case, the message is sent from the client to the KDC to request
   credentials for a service.

Top      Up      ToC       Page 74 
   The message fields are as follows:

AS-REQ          ::= [APPLICATION 10] KDC-REQ

TGS-REQ         ::= [APPLICATION 12] KDC-REQ

KDC-REQ         ::= SEQUENCE {
        -- NOTE: first tag is [1], not [0]
        pvno            [1] INTEGER (5) ,
        msg-type        [2] INTEGER (10 -- AS -- | 12 -- TGS --),
        padata          [3] SEQUENCE OF PA-DATA OPTIONAL
                            -- NOTE: not empty --,
        req-body        [4] KDC-REQ-BODY
}

KDC-REQ-BODY    ::= SEQUENCE {
        kdc-options             [0] KDCOptions,
        cname                   [1] PrincipalName OPTIONAL
                                    -- Used only in AS-REQ --,
        realm                   [2] Realm
                                    -- Server's realm
                                    -- Also client's in AS-REQ --,
        sname                   [3] PrincipalName OPTIONAL,
        from                    [4] KerberosTime OPTIONAL,
        till                    [5] KerberosTime,
        rtime                   [6] KerberosTime OPTIONAL,
        nonce                   [7] UInt32,
        etype                   [8] SEQUENCE OF Int32 -- EncryptionType
                                    -- in preference order --,
        addresses               [9] HostAddresses OPTIONAL,
        enc-authorization-data  [10] EncryptedData OPTIONAL
                                    -- AuthorizationData --,
        additional-tickets      [11] SEQUENCE OF Ticket OPTIONAL
                                       -- NOTE: not empty
}

KDCOptions      ::= KerberosFlags
        -- reserved(0),
        -- forwardable(1),
        -- forwarded(2),
        -- proxiable(3),
        -- proxy(4),
        -- allow-postdate(5),
        -- postdated(6),
        -- unused7(7),
        -- renewable(8),
        -- unused9(9),
        -- unused10(10),

Top      Up      ToC       Page 75 
        -- opt-hardware-auth(11),
        -- unused12(12),
        -- unused13(13),
-- 15 is reserved for canonicalize
        -- unused15(15),
-- 26 was unused in 1510
        -- disable-transited-check(26),
--
        -- renewable-ok(27),
        -- enc-tkt-in-skey(28),
        -- renew(30),
        -- validate(31)

   The fields in this message are as follows:

   pvno
      This field is included in each message, and specifies the protocol
      version number.  This document specifies protocol version 5.

   msg-type
      This field indicates the type of a protocol message.  It will
      almost always be the same as the application identifier associated
      with a message.  It is included to make the identifier more
      readily accessible to the application.  For the KDC-REQ message,
      this type will be KRB_AS_REQ or KRB_TGS_REQ.

   padata
      Contains pre-authentication data.  Requests for additional tickets
      (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ.

      The padata (pre-authentication data) field contains a sequence of
      authentication information that may be needed before credentials
      can be issued or decrypted.

   req-body
      This field is a placeholder delimiting the extent of the remaining
      fields.  If a checksum is to be calculated over the request, it is
      calculated over an encoding of the KDC-REQ-BODY sequence which is
      enclosed within the req-body field.

   kdc-options
      This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to
      the KDC and indicates the flags that the client wants set on the
      tickets as well as other information that is to modify the
      behavior of the KDC.  Where appropriate, the name of an option may
      be the same as the flag that is set by that option.  Although in
      most cases, the bit in the options field will be the same as that
      in the flags field, this is not guaranteed, so it is not

Top      Up      ToC       Page 76 
      acceptable simply to copy the options field to the flags field.
      There are various checks that must be made before an option is
      honored anyway.

      The kdc_options field is a bit-field, where the selected options
      are indicated by the bit being set (1), and the unselected options
      and reserved fields being reset (0).  The encoding of the bits is
      specified in Section 5.2.  The options are described in more
      detail above in Section 2.  The meanings of the options are as
      follows:

   Bits    Name                     Description

   0       RESERVED                 Reserved for future expansion of
                                    this field.

   1       FORWARDABLE              The FORWARDABLE option indicates
                                    that the ticket to be issued is to
                                    have its forwardable flag set.  It
                                    may only be set on the initial
                                    request, or in a subsequent request
                                    if the TGT on which it is based is
                                    also forwardable.

   2       FORWARDED                The FORWARDED option is only
                                    specified in a request to the
                                    ticket-granting server and will only
                                    be honored if the TGT in the request
                                    has its FORWARDABLE bit set.  This
                                    option indicates that this is a
                                    request for forwarding.  The
                                    address(es) of the host from which
                                    the resulting ticket is to be valid
                                    are included in the addresses field
                                    of the request.

   3       PROXIABLE                The PROXIABLE option indicates that
                                    the ticket to be issued is to have
                                    its proxiable flag set.  It may only
                                    be set on the initial request, or a
                                    subsequent request if the TGT on
                                    which it is based is also proxiable.

   4       PROXY                    The PROXY option indicates that this
                                    is a request for a proxy.  This
                                    option will only be honored if the
                                    TGT in the request has its PROXIABLE
                                    bit set.  The address(es) of the

Top      Up      ToC       Page 77 
                                    host from which the resulting ticket
                                    is to be valid are included in the
                                    addresses field of the request.

   5       ALLOW-POSTDATE           The ALLOW-POSTDATE option indicates
                                    that the ticket to be issued is to
                                    have its MAY-POSTDATE flag set.  It
                                    may only be set on the initial
                                    request, or in a subsequent request
                                    if the TGT on which it is based also
                                    has its MAY-POSTDATE flag set.

   6       POSTDATED                The POSTDATED option indicates that
                                    this is a request for a postdated
                                    ticket.  This option will only be
                                    honored if the TGT on which it is
                                    based has its MAY-POSTDATE flag set.
                                    The resulting ticket will also have
                                    its INVALID flag set, and that flag
                                    may be reset by a subsequent request
                                    to the KDC after the starttime in
                                    the ticket has been reached.

   7       RESERVED                 This option is presently unused.

   8       RENEWABLE                The RENEWABLE option indicates that
                                    the ticket to be issued is to have
                                    its RENEWABLE flag set.  It may only
                                    be set on the initial request, or
                                    when the TGT on which the request is
                                    based is also renewable.  If this
                                    option is requested, then the rtime
                                    field in the request contains the
                                    desired absolute expiration time for
                                    the ticket.

   9       RESERVED                 Reserved for PK-Cross.

   10      RESERVED                 Reserved for future use.

   11      RESERVED                 Reserved for opt-hardware-auth.

   12-25   RESERVED                 Reserved for future use.

   26      DISABLE-TRANSITED-CHECK  By default the KDC will check the
                                    transited field of a TGT against the
                                    policy of the local realm before it
                                    will issue derivative tickets based

Top      Up      ToC       Page 78 
                                    on the TGT.  If this flag is set in
                                    the request, checking of the
                                    transited field is disabled.
                                    Tickets issued without the
                                    performance of this check will be
                                    noted by the reset (0) value of the
                                    TRANSITED-POLICY-CHECKED flag,
                                    indicating to the application server
                                    that the transited field must be
                                    checked locally.  KDCs are
                                    encouraged but not required to honor
                                    the DISABLE-TRANSITED-CHECK option.

                                    This flag is new since RFC 1510.

   27      RENEWABLE-OK             The RENEWABLE-OK option indicates
                                    that a renewable ticket will be
                                    acceptable if a ticket with the
                                    requested life cannot otherwise be
                                    provided, in which case a renewable
                                    ticket may be issued with a renew-
                                    till equal to the requested endtime.
                                    The value of the renew-till field
                                    may still be limited by local
                                    limits, or limits selected by the
                                    individual principal or server.

   28      ENC-TKT-IN-SKEY          This option is used only by the
                                    ticket-granting service.  The ENC-
                                    TKT-IN-SKEY option indicates that
                                    the ticket for the end server is to
                                    be encrypted in the session key from
                                    the additional TGT provided.

   29      RESERVED                 Reserved for future use.

   30      RENEW                    This option is used only by the
                                    ticket-granting service.  The RENEW
                                    option indicates that the present
                                    request is for a renewal.  The
                                    ticket provided is encrypted in the
                                    secret key for the server on which
                                    it is valid.  This option will only
                                    be honored if the ticket to be
                                    renewed has its RENEWABLE flag set
                                    and if the time in its renew-till
                                    field has not passed.  The ticket to
                                    be renewed is passed in the padata

Top      Up      ToC       Page 79 
                                    field as part of the authentication
                                    header.

   31      VALIDATE                 This option is used only by the
                                    ticket-granting service.  The
                                    VALIDATE option indicates that the
                                    request is to validate a postdated
                                    ticket.  It will only be honored if
                                    the ticket presented is postdated,
                                    presently has its INVALID flag set,
                                    and would otherwise be usable at
                                    this time.  A ticket cannot be
                                    validated before its starttime.  The
                                    ticket presented for validation is
                                    encrypted in the key of the server
                                    for which it is valid and is passed
                                    in the padata field as part of the
                                    authentication header.

   cname and sname
      These fields are the same as those described for the ticket in
      section 5.3.  The sname may only be absent when the ENC-TKT-IN-
      SKEY option is specified.  If the sname is absent, the name of the
      server is taken from the name of the client in the ticket passed
      as additional-tickets.

   enc-authorization-data
      The enc-authorization-data, if present (and it can only be present
      in the TGS_REQ form), is an encoding of the desired
      authorization-data encrypted under the sub-session key if present
      in the Authenticator, or alternatively from the session key in the
      TGT (both the Authenticator and TGT come from the padata field in
      the KRB_TGS_REQ).  The key usage value used when encrypting is 5
      if a sub-session key is used, or 4 if the session key is used.

   realm
      This field specifies the realm part of the server's principal
      identifier.  In the AS exchange, this is also the realm part of
      the client's principal identifier.

   from
      This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket
      requests when the requested ticket is to be postdated.  It
      specifies the desired starttime for the requested ticket.  If this
      field is omitted, then the KDC SHOULD use the current time
      instead.

Top      Up      ToC       Page 80 
   till
      This field contains the expiration date requested by the client in
      a ticket request.  It is not optional, but if the requested
      endtime is "19700101000000Z", the requested ticket is to have the
      maximum endtime permitted according to KDC policy.  Implementation
      note: This special timestamp corresponds to a UNIX time_t value of
      zero on most systems.

   rtime
      This field is the requested renew-till time sent from a client to
      the KDC in a ticket request.  It is optional.

   nonce
      This field is part of the KDC request and response.  It is
      intended to hold a random number generated by the client.  If the
      same number is included in the encrypted response from the KDC, it
      provides evidence that the response is fresh and has not been
      replayed by an attacker.  Nonces MUST NEVER be reused.

   etype
      This field specifies the desired encryption algorithm to be used
      in the response.

   addresses
      This field is included in the initial request for tickets, and it
      is optionally included in requests for additional tickets from the
      ticket-granting server.  It specifies the addresses from which the
      requested ticket is to be valid.  Normally it includes the
      addresses for the client's host.  If a proxy is requested, this
      field will contain other addresses.  The contents of this field
      are usually copied by the KDC into the caddr field of the
      resulting ticket.

   additional-tickets
      Additional tickets MAY be optionally included in a request to the
      ticket-granting server.  If the ENC-TKT-IN-SKEY option has been
      specified, then the session key from the additional ticket will be
      used in place of the server's key to encrypt the new ticket.  When
      the ENC-TKT-IN-SKEY option is used for user-to-user
      authentication, this additional ticket MAY be a TGT issued by the
      local realm or an inter-realm TGT issued for the current KDC's
      realm by a remote KDC.  If more than one option that requires
      additional tickets has been specified, then the additional tickets
      are used in the order specified by the ordering of the options
      bits (see kdc-options, above).

Top      Up      ToC       Page 81 
   The application tag number will be either ten (10) or twelve (12)
   depending on whether the request is for an initial ticket (AS-REQ) or
   for an additional ticket (TGS-REQ).

   The optional fields (addresses, authorization-data, and additional-
   tickets) are only included if necessary to perform the operation
   specified in the kdc-options field.

   Note that in KRB_TGS_REQ, the protocol version number appears twice
   and two different message types appear: the KRB_TGS_REQ message
   contains these fields as does the authentication header (KRB_AP_REQ)
   that is passed in the padata field.

5.4.2.  KRB_KDC_REP Definition

   The KRB_KDC_REP message format is used for the reply from the KDC for
   either an initial (AS) request or a subsequent (TGS) request.  There
   is no message type for KRB_KDC_REP.  Instead, the type will be either
   KRB_AS_REP or KRB_TGS_REP.  The key used to encrypt the ciphertext
   part of the reply depends on the message type.  For KRB_AS_REP, the
   ciphertext is encrypted in the client's secret key, and the client's
   key version number is included in the key version number for the
   encrypted data.  For KRB_TGS_REP, the ciphertext is encrypted in the
   sub-session key from the Authenticator; if it is absent, the
   ciphertext is encrypted in the session key from the TGT used in the
   request.  In that case, no version number will be present in the
   EncryptedData sequence.

   The KRB_KDC_REP message contains the following fields:

   AS-REP          ::= [APPLICATION 11] KDC-REP

   TGS-REP         ::= [APPLICATION 13] KDC-REP

   KDC-REP         ::= SEQUENCE {
           pvno            [0] INTEGER (5),
           msg-type        [1] INTEGER (11 -- AS -- | 13 -- TGS --),
           padata          [2] SEQUENCE OF PA-DATA OPTIONAL
                                   -- NOTE: not empty --,
           crealm          [3] Realm,
           cname           [4] PrincipalName,
           ticket          [5] Ticket,
           enc-part        [6] EncryptedData
                                   -- EncASRepPart or EncTGSRepPart,
                                   -- as appropriate
   }

   EncASRepPart    ::= [APPLICATION 25] EncKDCRepPart

Top      Up      ToC       Page 82 
   EncTGSRepPart   ::= [APPLICATION 26] EncKDCRepPart

   EncKDCRepPart   ::= SEQUENCE {
           key             [0] EncryptionKey,
           last-req        [1] LastReq,
           nonce           [2] UInt32,
           key-expiration  [3] KerberosTime OPTIONAL,
           flags           [4] TicketFlags,
           authtime        [5] KerberosTime,
           starttime       [6] KerberosTime OPTIONAL,
           endtime         [7] KerberosTime,
           renew-till      [8] KerberosTime OPTIONAL,
           srealm          [9] Realm,
           sname           [10] PrincipalName,
           caddr           [11] HostAddresses OPTIONAL
   }

   LastReq         ::=     SEQUENCE OF SEQUENCE {
           lr-type         [0] Int32,
           lr-value        [1] KerberosTime
   }

   pvno and msg-type
      These fields are described above in Section 5.4.1.  msg-type is
      either KRB_AS_REP or KRB_TGS_REP.

   padata
      This field is described in detail in Section 5.4.1.  One possible
      use for it is to encode an alternate "salt" string to be used with
      a string-to-key algorithm.  This ability is useful for easing
      transitions if a realm name needs to change (e.g., when a company
      is acquired); in such a case all existing password-derived entries
      in the KDC database would be flagged as needing a special salt
      string until the next password change.

   crealm, cname, srealm, and sname
      These fields are the same as those described for the ticket in
      section 5.3.

   ticket
      The newly-issued ticket, from Section 5.3.

   enc-part
      This field is a place holder for the ciphertext and related
      information that forms the encrypted part of a message.  The
      description of the encrypted part of the message follows each
      appearance of this field.

Top      Up      ToC       Page 83 
      The key usage value for encrypting this field is 3 in an AS-REP
      message, using the client's long-term key or another key selected
      via pre-authentication mechanisms.  In a TGS-REP message, the key
      usage value is 8 if the TGS session key is used, or 9 if a TGS
      authenticator subkey is used.

      Compatibility note: Some implementations unconditionally send an
      encrypted EncTGSRepPart (application tag number 26) in this field
      regardless of whether the reply is a AS-REP or a TGS-REP.  In the
      interest of compatibility, implementors MAY relax the check on the
      tag number of the decrypted ENC-PART.

   key
      This field is the same as described for the ticket in Section 5.3.

   last-req
      This field is returned by the KDC and specifies the time(s) of the
      last request by a principal.  Depending on what information is
      available, this might be the last time that a request for a TGT
      was made, or the last time that a request based on a TGT was
      successful.  It also might cover all servers for a realm, or just
      the particular server.  Some implementations MAY display this
      information to the user to aid in discovering unauthorized use of
      one's identity.  It is similar in spirit to the last login time
      displayed when logging in to timesharing systems.

   lr-type
      This field indicates how the following lr-value field is to be
      interpreted.  Negative values indicate that the information
      pertains only to the responding server.  Non-negative values
      pertain to all servers for the realm.

      If the lr-type field is zero (0), then no information is conveyed
      by the lr-value subfield.  If the absolute value of the lr-type
      field is one (1), then the lr-value subfield is the time of last
      initial request for a TGT.  If it is two (2), then the lr-value
      subfield is the time of last initial request.  If it is three (3),
      then the lr-value subfield is the time of issue for the newest TGT
      used.  If it is four (4), then the lr-value subfield is the time
      of the last renewal.  If it is five (5), then the lr-value
      subfield is the time of last request (of any type).  If it is (6),
      then the lr-value subfield is the time when the password will
      expire.  If it is (7), then the lr-value subfield is the time when
      the account will expire.

Top      Up      ToC       Page 84 
   lr-value
      This field contains the time of the last request.  The time MUST
      be interpreted according to the contents of the accompanying lr-
      type subfield.

   nonce
      This field is described above in Section 5.4.1.

   key-expiration
      The key-expiration field is part of the response from the KDC and
      specifies the time that the client's secret key is due to expire.
      The expiration might be the result of password aging or an account
      expiration.  If present, it SHOULD be set to the earlier of the
      user's key expiration and account expiration.  The use of this
      field is deprecated, and the last-req field SHOULD be used to
      convey this information instead.  This field will usually be left
      out of the TGS reply since the response to the TGS request is
      encrypted in a session key and no client information has to be
      retrieved from the KDC database.  It is up to the application
      client (usually the login program) to take appropriate action
      (such as notifying the user) if the expiration time is imminent.

   flags, authtime, starttime, endtime, renew-till and caddr
      These fields are duplicates of those found in the encrypted
      portion of the attached ticket (see Section 5.3), provided so the
      client MAY verify that they match the intended request and in
      order to assist in proper ticket caching.  If the message is of
      type KRB_TGS_REP, the caddr field will only be filled in if the
      request was for a proxy or forwarded ticket, or if the user is
      substituting a subset of the addresses from the TGT.  If the
      client-requested addresses are not present or not used, then the
      addresses contained in the ticket will be the same as those
      included in the TGT.

5.5.  Client/Server (CS) Message Specifications

   This section specifies the format of the messages used for the
   authentication of the client to the application server.

5.5.1.  KRB_AP_REQ Definition

   The KRB_AP_REQ message contains the Kerberos protocol version number,
   the message type KRB_AP_REQ, an options field to indicate any options
   in use, and the ticket and authenticator themselves.  The KRB_AP_REQ
   message is often referred to as the "authentication header".

Top      Up      ToC       Page 85 
   AP-REQ          ::= [APPLICATION 14] SEQUENCE {
           pvno            [0] INTEGER (5),
           msg-type        [1] INTEGER (14),
           ap-options      [2] APOptions,
           ticket          [3] Ticket,
           authenticator   [4] EncryptedData -- Authenticator
   }

   APOptions       ::= KerberosFlags
           -- reserved(0),
           -- use-session-key(1),
           -- mutual-required(2)

   pvno and msg-type
      These fields are described above in Section 5.4.1. msg-type is
      KRB_AP_REQ.

   ap-options
      This field appears in the application request (KRB_AP_REQ) and
      affects the way the request is processed.  It is a bit-field,
      where the selected options are indicated by the bit being set (1),
      and the unselected options and reserved fields by being reset (0).
      The encoding of the bits is specified in Section 5.2.  The
      meanings of the options are as follows:

   Bit(s)  Name             Description

   0       reserved         Reserved for future expansion of this field.

   1       use-session-key  The USE-SESSION-KEY option indicates that
                            the ticket the client is presenting to a
                            server is encrypted in the session key from
                            the server's TGT.  When this option is not
                            specified, the ticket is encrypted in the
                            server's secret key.

   2       mutual-required  The MUTUAL-REQUIRED option tells the server
                            that the client requires mutual
                            authentication, and that it must respond
                            with a KRB_AP_REP message.

   3-31    reserved         Reserved for future use.

   ticket
      This field is a ticket authenticating the client to the server.

Top      Up      ToC       Page 86 
   authenticator
      This contains the encrypted authenticator, which includes the
      client's choice of a subkey.

   The encrypted authenticator is included in the AP-REQ; it certifies
   to a server that the sender has recent knowledge of the encryption
   key in the accompanying ticket, to help the server detect replays.
   It also assists in the selection of a "true session key" to use with
   the particular session.  The DER encoding of the following is
   encrypted in the ticket's session key, with a key usage value of 11
   in normal application exchanges, or 7 when used as the PA-TGS-REQ
   PA-DATA field of a TGS-REQ exchange (see Section 5.4.1):

   -- Unencrypted authenticator
   Authenticator   ::= [APPLICATION 2] SEQUENCE  {
           authenticator-vno       [0] INTEGER (5),
           crealm                  [1] Realm,
           cname                   [2] PrincipalName,
           cksum                   [3] Checksum OPTIONAL,
           cusec                   [4] Microseconds,
           ctime                   [5] KerberosTime,
           subkey                  [6] EncryptionKey OPTIONAL,
           seq-number              [7] UInt32 OPTIONAL,
           authorization-data      [8] AuthorizationData OPTIONAL
   }

   authenticator-vno
      This field specifies the version number for the format of the
      authenticator.  This document specifies version 5.

   crealm and cname
      These fields are the same as those described for the ticket in
      section 5.3.

   cksum
      This field contains a checksum of the application data that
      accompanies the KRB_AP_REQ, computed using a key usage value of 10
      in normal application exchanges, or 6 when used in the TGS-REQ
      PA-TGS-REQ AP-DATA field.

   cusec
      This field contains the microsecond part of the client's
      timestamp.  Its value (before encryption) ranges from 0 to 999999.
      It often appears along with ctime.  The two fields are used
      together to specify a reasonably accurate timestamp.

   ctime
      This field contains the current time on the client's host.

Top      Up      ToC       Page 87 
   subkey
      This field contains the client's choice for an encryption key to
      be used to protect this specific application session.  Unless an
      application specifies otherwise, if this field is left out, the
      session key from the ticket will be used.

   seq-number
      This optional field includes the initial sequence number to be
      used by the KRB_PRIV or KRB_SAFE messages when sequence numbers
      are used to detect replays.  (It may also be used by application
      specific messages.)  When included in the authenticator, this
      field specifies the initial sequence number for messages from the
      client to the server.  When included in the AP-REP message, the
      initial sequence number is that for messages from the server to
      the client.  When used in KRB_PRIV or KRB_SAFE messages, it is
      incremented by one after each message is sent.  Sequence numbers
      fall in the range 0 through 2^32 - 1 and wrap to zero following
      the value 2^32 - 1.

      For sequence numbers to support the detection of replays
      adequately, they SHOULD be non-repeating, even across connection
      boundaries.  The initial sequence number SHOULD be random and
      uniformly distributed across the full space of possible sequence
      numbers, so that it cannot be guessed by an attacker and so that
      it and the successive sequence numbers do not repeat other
      sequences.  In the event that more than 2^32 messages are to be
      generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying
      SHOULD be performed before sequence numbers are reused with the
      same encryption key.

      Implmentation note: Historically, some implementations transmit
      signed twos-complement numbers for sequence numbers.  In the
      interests of compatibility, implementations MAY accept the
      equivalent negative number where a positive number greater than
      2^31 - 1 is expected.

      Implementation note: As noted before, some implementations omit
      the optional sequence number when its value would be zero.
      Implementations MAY accept an omitted sequence number when
      expecting a value of zero, and SHOULD NOT transmit an
      Authenticator with a initial sequence number of zero.

   authorization-data
      This field is the same as described for the ticket in Section 5.3.
      It is optional and will only appear when additional restrictions
      are to be placed on the use of a ticket, beyond those carried in
      the ticket itself.

Top      Up      ToC       Page 88 
5.5.2.  KRB_AP_REP Definition

   The KRB_AP_REP message contains the Kerberos protocol version number,
   the message type, and an encrypted time-stamp.  The message is sent
   in response to an application request (KRB_AP_REQ) for which the
   mutual authentication option has been selected in the ap-options
   field.

   AP-REP          ::= [APPLICATION 15] SEQUENCE {
           pvno            [0] INTEGER (5),
           msg-type        [1] INTEGER (15),
           enc-part        [2] EncryptedData -- EncAPRepPart
   }

   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
           ctime           [0] KerberosTime,
           cusec           [1] Microseconds,
           subkey          [2] EncryptionKey OPTIONAL,
           seq-number      [3] UInt32 OPTIONAL
   }

   The encoded EncAPRepPart is encrypted in the shared session key of
   the ticket.  The optional subkey field can be used in an
   application-arranged negotiation to choose a per association session
   key.

   pvno and msg-type
      These fields are described above in Section 5.4.1.  msg-type is
      KRB_AP_REP.

   enc-part
      This field is described above in Section 5.4.2.  It is computed
      with a key usage value of 12.

   ctime
      This field contains the current time on the client's host.

   cusec
      This field contains the microsecond part of the client's
      timestamp.

   subkey
      This field contains an encryption key that is to be used to
      protect this specific application session.  See Section 3.2.6 for
      specifics on how this field is used to negotiate a key.  Unless an
      application specifies otherwise, if this field is left out, the
      sub-session key from the authenticator or if the latter is also
      left out, the session key from the ticket will be used.

Top      Up      ToC       Page 89 
   seq-number
      This field is described above in Section 5.3.2.

5.5.3.  Error Message Reply

   If an error occurs while processing the application request, the
   KRB_ERROR message will be sent in response.  See Section 5.9.1 for
   the format of the error message.  The cname and crealm fields MAY be
   left out if the server cannot determine their appropriate values from
   the corresponding KRB_AP_REQ message.  If the authenticator was
   decipherable, the ctime and cusec fields will contain the values from
   it.

5.6.  KRB_SAFE Message Specification

   This section specifies the format of a message that can be used by
   either side (client or server) of an application to send a tamper-
   proof message to its peer.  It presumes that a session key has
   previously been exchanged (for example, by using the
   KRB_AP_REQ/KRB_AP_REP messages).

5.6.1.  KRB_SAFE definition

   The KRB_SAFE message contains user data along with a collision-proof
   checksum keyed with the last encryption key negotiated via subkeys,
   or with the session key if no negotiation has occurred.  The message
   fields are as follows:

   KRB-SAFE        ::= [APPLICATION 20] SEQUENCE {
           pvno            [0] INTEGER (5),
           msg-type        [1] INTEGER (20),
           safe-body       [2] KRB-SAFE-BODY,
           cksum           [3] Checksum
   }

   KRB-SAFE-BODY   ::= SEQUENCE {
           user-data       [0] OCTET STRING,
           timestamp       [1] KerberosTime OPTIONAL,
           usec            [2] Microseconds OPTIONAL,
           seq-number      [3] UInt32 OPTIONAL,
           s-address       [4] HostAddress,
           r-address       [5] HostAddress OPTIONAL
   }

   pvno and msg-type
      These fields are described above in Section 5.4.1.  msg-type is
      KRB_SAFE.

Top      Up      ToC       Page 90 
   safe-body
      This field is a placeholder for the body of the KRB-SAFE message.

   cksum
      This field contains the checksum of the application data, computed
      with a key usage value of 15.

      The checksum is computed over the encoding of the KRB-SAFE
      sequence.  First, the cksum is set to a type zero, zero-length
      value, and the checksum is computed over the encoding of the KRB-
      SAFE sequence.  Then the checksum is set to the result of that
      computation.  Finally, the KRB-SAFE sequence is encoded again.
      This method, although different than the one specified in RFC
      1510, corresponds to existing practice.

   user-data
      This field is part of the KRB_SAFE and KRB_PRIV messages, and
      contains the application-specific data that is being passed from
      the sender to the recipient.

   timestamp
      This field is part of the KRB_SAFE and KRB_PRIV messages.  Its
      contents are the current time as known by the sender of the
      message.  By checking the timestamp, the recipient of the message
      is able to make sure that it was recently generated, and is not a
      replay.

   usec
      This field is part of the KRB_SAFE and KRB_PRIV headers.  It
      contains the microsecond part of the timestamp.

   seq-number
      This field is described above in Section 5.3.2.

   s-address
      Sender's address.

      This field specifies the address in use by the sender of the
      message.

   r-address
      This field specifies the address in use by the recipient of the
      message.  It MAY be omitted for some uses (such as broadcast
      protocols), but the recipient MAY arbitrarily reject such
      messages.  This field, along with s-address, can be used to help
      detect messages that have been incorrectly or maliciously
      delivered to the wrong recipient.

Top      Up      ToC       Page 91 
5.7.  KRB_PRIV Message Specification

   This section specifies the format of a message that can be used by
   either side (client or server) of an application to send a message to
   its peer securely and privately.  It presumes that a session key has
   previously been exchanged (for example, by using the
   KRB_AP_REQ/KRB_AP_REP messages).

5.7.1.  KRB_PRIV Definition

   The KRB_PRIV message contains user data encrypted in the Session Key.
   The message fields are as follows:

   KRB-PRIV        ::= [APPLICATION 21] SEQUENCE {
           pvno            [0] INTEGER (5),
           msg-type        [1] INTEGER (21),
                           -- NOTE: there is no [2] tag
           enc-part        [3] EncryptedData -- EncKrbPrivPart
   }

   EncKrbPrivPart  ::= [APPLICATION 28] SEQUENCE {
           user-data       [0] OCTET STRING,
           timestamp       [1] KerberosTime OPTIONAL,
           usec            [2] Microseconds OPTIONAL,
           seq-number      [3] UInt32 OPTIONAL,
           s-address       [4] HostAddress -- sender's addr --,
           r-address       [5] HostAddress OPTIONAL -- recip's addr
   }

   pvno and msg-type
      These fields are described above in Section 5.4.1.  msg-type is
      KRB_PRIV.

   enc-part
      This field holds an encoding of the EncKrbPrivPart sequence
      encrypted under the session key, with a key usage value of 13.
      This encrypted encoding is used for the enc-part field of the
      KRB-PRIV message.

   user-data, timestamp, usec, s-address, and r-address
      These fields are described above in Section 5.6.1.

   seq-number
      This field is described above in Section 5.3.2.

Top      Up      ToC       Page 92 
5.8.  KRB_CRED Message Specification

   This section specifies the format of a message that can be used to
   send Kerberos credentials from one principal to another.  It is
   presented here to encourage a common mechanism to be used by
   applications when forwarding tickets or providing proxies to
   subordinate servers.  It presumes that a session key has already been
   exchanged, perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.

5.8.1.  KRB_CRED Definition

   The KRB_CRED message contains a sequence of tickets to be sent and
   information needed to use the tickets, including the session key from
   each.  The information needed to use the tickets is encrypted under
   an encryption key previously exchanged or transferred alongside the
   KRB_CRED message.  The message fields are as follows:

   KRB-CRED        ::= [APPLICATION 22] SEQUENCE {
           pvno            [0] INTEGER (5),
           msg-type        [1] INTEGER (22),
           tickets         [2] SEQUENCE OF Ticket,
           enc-part        [3] EncryptedData -- EncKrbCredPart
   }

   EncKrbCredPart  ::= [APPLICATION 29] SEQUENCE {
           ticket-info     [0] SEQUENCE OF KrbCredInfo,
           nonce           [1] UInt32 OPTIONAL,
           timestamp       [2] KerberosTime OPTIONAL,
           usec            [3] Microseconds OPTIONAL,
           s-address       [4] HostAddress OPTIONAL,
           r-address       [5] HostAddress OPTIONAL
   }

   KrbCredInfo     ::= SEQUENCE {
           key             [0] EncryptionKey,
           prealm          [1] Realm OPTIONAL,
           pname           [2] PrincipalName OPTIONAL,
           flags           [3] TicketFlags OPTIONAL,
           authtime        [4] KerberosTime OPTIONAL,
           starttime       [5] KerberosTime OPTIONAL,
           endtime         [6] KerberosTime OPTIONAL,
           renew-till      [7] KerberosTime OPTIONAL,
           srealm          [8] Realm OPTIONAL,
           sname           [9] PrincipalName OPTIONAL,
           caddr           [10] HostAddresses OPTIONAL
   }

Top      Up      ToC       Page 93 
   pvno and msg-type
      These fields are described above in Section 5.4.1.  msg-type is
      KRB_CRED.

   tickets
      These are the tickets obtained from the KDC specifically for use
      by the intended recipient.  Successive tickets are paired with the
      corresponding KrbCredInfo sequence from the enc-part of the KRB-
      CRED message.

   enc-part
      This field holds an encoding of the EncKrbCredPart sequence
      encrypted under the session key shared by the sender and the
      intended recipient, with a key usage value of 14.  This encrypted
      encoding is used for the enc-part field of the KRB-CRED message.

      Implementation note: Implementations of certain applications, most
      notably certain implementations of the Kerberos GSS-API mechanism,
      do not separately encrypt the contents of the EncKrbCredPart of
      the KRB-CRED message when sending it.  In the case of those GSS-
      API mechanisms, this is not a security vulnerability, as the
      entire KRB-CRED message is itself embedded in an encrypted
      message.

   nonce
      If practical, an application MAY require the inclusion of a nonce
      generated by the recipient of the message.  If the same value is
      included as the nonce in the message, it provides evidence that
      the message is fresh and has not been replayed by an attacker.  A
      nonce MUST NEVER be reused.

   timestamp and usec
      These fields specify the time that the KRB-CRED message was
      generated.  The time is used to provide assurance that the message
      is fresh.

   s-address and r-address
      These fields are described above in Section 5.6.1.  They are used
      optionally to provide additional assurance of the integrity of the
      KRB-CRED message.

   key
      This field exists in the corresponding ticket passed by the KRB-
      CRED message and is used to pass the session key from the sender
      to the intended recipient.  The field's encoding is described in
      Section 5.2.9.

Top      Up      ToC       Page 94 
   The following fields are optional.  If present, they can be
   associated with the credentials in the remote ticket file.  If left
   out, then it is assumed that the recipient of the credentials already
   knows their values.

   prealm and pname
      The name and realm of the delegated principal identity.

   flags, authtime, starttime, endtime, renew-till, srealm, sname,
   and caddr
      These fields contain the values of the corresponding fields from
      the ticket found in the ticket field.  Descriptions of the fields
      are identical to the descriptions in the KDC-REP message.

5.9.  Error Message Specification

   This section specifies the format for the KRB_ERROR message.  The
   fields included in the message are intended to return as much
   information as possible about an error.  It is not expected that all
   the information required by the fields will be available for all
   types of errors.  If the appropriate information is not available
   when the message is composed, the corresponding field will be left
   out of the message.

   Note that because the KRB_ERROR message is not integrity protected,
   it is quite possible for an intruder to synthesize or modify it.  In
   particular, this means that the client SHOULD NOT use any fields in
   this message for security-critical purposes, such as setting a system
   clock or generating a fresh authenticator.  The message can be
   useful, however, for advising a user on the reason for some failure.

5.9.1.  KRB_ERROR Definition

   The KRB_ERROR message consists of the following fields:

   KRB-ERROR       ::= [APPLICATION 30] SEQUENCE {
           pvno            [0] INTEGER (5),
           msg-type        [1] INTEGER (30),
           ctime           [2] KerberosTime OPTIONAL,
           cusec           [3] Microseconds OPTIONAL,
           stime           [4] KerberosTime,
           susec           [5] Microseconds,
           error-code      [6] Int32,
           crealm          [7] Realm OPTIONAL,
           cname           [8] PrincipalName OPTIONAL,
           realm           [9] Realm -- service realm --,
           sname           [10] PrincipalName -- service name --,
           e-text          [11] KerberosString OPTIONAL,

Top      Up      ToC       Page 95 
           e-data          [12] OCTET STRING OPTIONAL
   }

   pvno and msg-type
      These fields are described above in Section 5.4.1.  msg-type is
      KRB_ERROR.

   ctime and cusec
      These fields are described above in Section 5.5.2.  If the values
      for these fields are known to the entity generating the error (as
      they would be if the KRB-ERROR is generated in reply to, e.g., a
      failed authentication service request), they should be populated
      in the KRB-ERROR.  If the values are not available, these fields
      can be omitted.

   stime
      This field contains the current time on the server.  It is of type
      KerberosTime.

   susec
      This field contains the microsecond part of the server's
      timestamp.  Its value ranges from 0 to 999999.  It appears along
      with stime.  The two fields are used in conjunction to specify a
      reasonably accurate timestamp.

   error-code
      This field contains the error code returned by Kerberos or the
      server when a request fails.  To interpret the value of this field
      see the list of error codes in Section 7.5.9.  Implementations are
      encouraged to provide for national language support in the display
      of error messages.

   crealm, and cname
      These fields are described above in Section 5.3.  When the entity
      generating the error knows these values, they should be populated
      in the KRB-ERROR.  If the values are not known, the crealm and
      cname fields SHOULD be omitted.

   realm and sname
      These fields are described above in Section 5.3.

   e-text
      This field contains additional text to help explain the error code
      associated with the failed request (for example, it might include
      a principal name which was unknown).

Top      Up      ToC       Page 96 
   e-data
      This field contains additional data about the error for use by the
      application to help it recover from or handle the error.  If the
      errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will
      contain an encoding of a sequence of padata fields, each
      corresponding to an acceptable pre-authentication method and
      optionally containing data for the method:

      METHOD-DATA     ::= SEQUENCE OF PA-DATA

   For error codes defined in this document other than
   KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field
   are implementation-defined.  Similarly, for future error codes, the
   format and contents of the e-data field are implementation-defined
   unless specified otherwise.  Whether defined by the implementation or
   in a future document, the e-data field MAY take the form of TYPED-
   DATA:

   TYPED-DATA      ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
           data-type       [0] Int32,
           data-value      [1] OCTET STRING OPTIONAL
   }

5.10.  Application Tag Numbers

   The following table lists the application class tag numbers used by
   various data types defined in this section.

   Tag Number(s)  Type Name      Comments

   0                             unused

   1              Ticket         PDU

   2              Authenticator  non-PDU

   3              EncTicketPart  non-PDU

   4-9                           unused

   10             AS-REQ         PDU

   11             AS-REP         PDU

   12             TGS-REQ        PDU

   13             TGS-REP        PDU

Top      Up      ToC       Page 97 
   14             AP-REQ         PDU

   15             AP-REP         PDU

   16             RESERVED16     TGT-REQ (for user-to-user)

   17             RESERVED17     TGT-REP (for user-to-user)

   18-19                         unused

   20             KRB-SAFE       PDU

   21             KRB-PRIV       PDU

   22             KRB-CRED       PDU

   23-24                         unused

   25             EncASRepPart   non-PDU

   26             EncTGSRepPart  non-PDU

   27             EncApRepPart   non-PDU

   28             EncKrbPrivPart non-PDU

   29             EncKrbCredPart non-PDU

   30             KRB-ERROR      PDU

   The ASN.1 types marked above as "PDU" (Protocol Data Unit) are the
   only ASN.1 types intended as top-level types of the Kerberos
   protocol, and are the only types that may be used as elements in
   another protocol that makes use of Kerberos.

6.  Naming Constraints

6.1.  Realm Names

   Although realm names are encoded as GeneralStrings and technically a
   realm can select any name it chooses, interoperability across realm
   boundaries requires agreement on how realm names are to be assigned,
   and what information they imply.

   To enforce these conventions, each realm MUST conform to the
   conventions itself, and it MUST require that any realms with which
   inter-realm keys are shared also conform to the conventions and
   require the same from its neighbors.

Top      Up      ToC       Page 98 
   Kerberos realm names are case sensitive.  Realm names that differ
   only in the case of the characters are not equivalent.  There are
   presently three styles of realm names: domain, X500, and other.
   Examples of each style follow:

        domain:   ATHENA.MIT.EDU
          X500:   C=US/O=OSF
         other:   NAMETYPE:rest/of.name=without-restrictions

   Domain style realm names MUST look like domain names: they consist of
   components separated by periods (.) and they contain neither colons
   (:) nor slashes (/).  Though domain names themselves are case
   insensitive, in order for realms to match, the case must match as
   well.  When establishing a new realm name based on an internet domain
   name it is recommended by convention that the characters be converted
   to uppercase.

   X.500 names contain an equals sign (=) and cannot contain a colon (:)
   before the equals sign.  The realm names for X.500 names will be
   string representations of the names with components separated by
   slashes.  Leading and trailing slashes will not be included.  Note
   that the slash separator is consistent with Kerberos implementations
   based on RFC 1510, but it is different from the separator recommended
   in RFC 2253.

   Names that fall into the other category MUST begin with a prefix that
   contains no equals sign (=) or period (.), and the prefix MUST be
   followed by a colon (:) and the rest of the name.  All prefixes
   expect those beginning with used.  Presently none are assigned.

   The reserved category includes strings that do not fall into the
   first three categories.  All names in this category are reserved.  It
   is unlikely that names will be assigned to this category unless there
   is a very strong argument for not using the 'other' category.

   These rules guarantee that there will be no conflicts between the
   various name styles.  The following additional constraints apply to
   the assignment of realm names in the domain and X.500 categories:
   either the name of a realm for the domain or X.500 formats must be
   used by the organization owning (to whom it was assigned) an Internet
   domain name or X.500 name, or, in the case that no such names are
   registered, authority to use a realm name MAY be derived from the
   authority of the parent realm.  For example, if there is no domain
   name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can
   authorize the creation of a realm with that name.

   This is acceptable because the organization to which the parent is
   assigned is presumably the organization authorized to assign names to

Top      Up      ToC       Page 99 
   its children in the X.500 and domain name systems as well.  If the
   parent assigns a realm name without also registering it in the domain
   name or X.500 hierarchy, it is the parent's responsibility to make
   sure that in the future there will not exist a name identical to the
   realm name of the child unless it is assigned to the same entity as
   the realm name.

6.2.  Principal Names

   As was the case for realm names, conventions are needed to ensure
   that all agree on what information is implied by a principal name.
   The name-type field that is part of the principal name indicates the
   kind of information implied by the name.  The name-type SHOULD be
   treated only as a hint to interpreting the meaning of a name.  It is
   not significant when checking for equivalence.  Principal names that
   differ only in the name-type identify the same principal.  The name
   type does not partition the name space.  Ignoring the name type, no
   two names can be the same (i.e., at least one of the components, or
   the realm, MUST be different).  The following name types are defined:

   Name Type       Value  Meaning

   NT-UNKNOWN        0    Name type not known
   NT-PRINCIPAL      1    Just the name of the principal as in DCE,
                            or for users
   NT-SRV-INST       2    Service and other unique instance (krbtgt)
   NT-SRV-HST        3    Service with host name as instance
                            (telnet, rcommands)
   NT-SRV-XHST       4    Service with host as remaining components
   NT-UID            5    Unique ID
   NT-X500-PRINCIPAL 6    Encoded X.509 Distinguished name [RFC2253]
   NT-SMTP-NAME      7    Name in form of SMTP email name
                            (e.g., user@example.com)
   NT-ENTERPRISE    10    Enterprise name - may be mapped to principal
                            name

   When a name implies no information other than its uniqueness at a
   particular time, the name type PRINCIPAL SHOULD be used.  The
   principal name type SHOULD be used for users, and it might also be
   used for a unique server.  If the name is a unique machine-generated
   ID that is guaranteed never to be reassigned, then the name type of
   UID SHOULD be used.  (Note that it is generally a bad idea to
   reassign names of any type since stale entries might remain in access
   control lists.)

   If the first component of a name identifies a service and the
   remaining components identify an instance of the service in a
   server-specified manner, then the name type of SRV-INST SHOULD be

Top      Up      ToC       Page 100 
   used.  An example of this name type is the Kerberos ticket-granting
   service whose name has a first component of krbtgt and a second
   component identifying the realm for which the ticket is valid.

   If the first component of a name identifies a service and there is a
   single component following the service name identifying the instance
   as the host on which the server is running, then the name type
   SRV-HST SHOULD be used.  This type is typically used for Internet
   services such as telnet and the Berkeley R commands.  If the separate
   components of the host name appear as successive components following
   the name of the service, then the name type SRV-XHST SHOULD be used.
   This type might be used to identify servers on hosts with X.500
   names, where the slash (/) might otherwise be ambiguous.

   A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an
   X.509 certificate is translated into a Kerberos name.  The encoding
   of the X.509 name as a Kerberos principal shall conform to the
   encoding rules specified in RFC 2253.

   A name type of SMTP allows a name to be of a form that resembles an
   SMTP email name.  This name, including an "@" and a domain name, is
   used as the one component of the principal name.

   A name type of UNKNOWN SHOULD be used when the form of the name is
   not known.  When comparing names, a name of type UNKNOWN will match
   principals authenticated with names of any type.  A principal
   authenticated with a name of type UNKNOWN, however, will only match
   other names of type UNKNOWN.

   Names of any type with an initial component of 'krbtgt' are reserved
   for the Kerberos ticket-granting service.  See Section 7.3 for the
   form of such names.

6.2.1.  Name of Server Principals

   The principal identifier for a server on a host will generally be
   composed of two parts: (1) the realm of the KDC with which the server
   is registered, and (2) a two-component name of type NT-SRV-HST, if
   the host name is an Internet domain name, or a multi-component name
   of type NT-SRV-XHST, if the name of the host is of a form (such as
   X.500) that allows slash (/) separators.  The first component of the
   two- or multi-component name will identify the service, and the
   latter components will identify the host.  Where the name of the host
   is not case sensitive (for example, with Internet domain names) the
   name of the host MUST be lowercase.  If specified by the application
   protocol for services such as telnet and the Berkeley R commands that
   run with system privileges, the first component MAY be the string
   'host' instead of a service-specific identifier.


Next RFC Part