7.  Constants and Other Defined Values

7.1.  Host Address Types

   All negative values for the host address type are reserved for local
   use.  All non-negative values are reserved for officially assigned
   type fields and interpretations.

   Internet (IPv4) Addresses

      Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded
      in MSB order (most significant byte first).  The IPv4 loopback
      address SHOULD NOT appear in a Kerberos PDU.  The type of IPv4
      addresses is two (2).

   Internet (IPv6) Addresses

      IPv6 addresses [RFC3513] are 128-bit (16-octet) quantities,
      encoded in MSB order (most significant byte first).  The type of
      IPv6 addresses is twenty-four (24).  The following addresses MUST
      NOT appear in any Kerberos PDU:

         *  the Unspecified Address
         *  the Loopback Address
         *  Link-Local addresses

      This restriction applies to the inclusion in the address fields of
      Kerberos PDUs, but not to the address fields of packets that might
      carry such PDUs.  The restriction is necessary because the use of
      an address with non-global scope could allow the acceptance of a
      message sent from a node that may have the same address, but which
      is not the host intended by the entity that added the restriction.
      If the link-local address type needs to be used for communication,
      then the address restriction in tickets must not be used (i.e.,
      addressless tickets must be used).

      IPv4-mapped IPv6 addresses MUST be represented as addresses of
      type 2.

   DECnet Phase IV Addresses

      DECnet Phase IV addresses are 16-bit addresses, encoded in LSB
      order.  The type of DECnet Phase IV addresses is twelve (12).

   Netbios Addresses

      Netbios addresses are 16-octet addresses typically composed of 1
      to 15 alphanumeric characters and padded with the US-ASCII SPC
      character (code 32).  The 16th octet MUST be the US-ASCII NUL
      character (code 0).  The type of Netbios addresses is twenty (20).

   Directional Addresses

      Including the sender address in KRB_SAFE and KRB_PRIV messages is
      undesirable in many environments because the addresses may be
      changed in transport by network address translators.  However, if
      these addresses are removed, the messages may be subject to a
      reflection attack in which a message is reflected back to its
      originator.  The directional address type provides a way to avoid
      transport addresses and reflection attacks.  Directional addresses
      are encoded as four-byte unsigned integers in network byte order.
      If the message is originated by the party sending the original
      KRB_AP_REQ message, then an address of 0 SHOULD be used.  If the
      message is originated by the party to whom that KRB_AP_REQ was
      sent, then the address 1 SHOULD be used.  Applications involving
      multiple parties can specify the use of other addresses.

      Directional addresses MUST only be used for the sender address
      field in the KRB_SAFE or KRB_PRIV messages.  They MUST NOT be used
      as a ticket address or in a KRB_AP_REQ message.  This address type
      SHOULD only be used in situations where the sending party knows
      that the receiving party supports the address type.  This
      generally means that directional addresses may only be used when
      the application protocol requires their support.  Directional
      addresses are type (3).

7.2.  KDC Messaging: IP Transports

   Kerberos defines two IP transport mechanisms for communication
   between clients and servers: UDP/IP and TCP/IP.

7.2.1.  UDP/IP transport

   Kerberos servers (KDCs) supporting IP transports MUST accept UDP
   requests and SHOULD listen for them on port 88 (decimal) unless
   specifically configured to listen on an alternative UDP port.
   Alternate ports MAY be used when running multiple KDCs for multiple
   realms on the same host.

   Kerberos clients supporting IP transports SHOULD support the sending
   of UDP requests.  Clients SHOULD use KDC discovery [7.2.3] to
   identify the IP address and port to which they will send their
   request.

   When contacting a KDC for a KRB_KDC_REQ request using UDP/IP
   transport, the client shall send a UDP datagram containing only an
   encoding of the request to the KDC.  The KDC will respond with a
   reply datagram containing only an encoding of the reply message
   (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at the
   sender's IP address.  The response to a request made through UDP/IP
   transport MUST also use UDP/IP transport.  If the response cannot be
   handled using UDP (for example, because it is too large), the KDC
   MUST return KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the
   request using the TCP transport.

7.2.2.  TCP/IP Transport

   Kerberos servers (KDCs) supporting IP transports MUST accept TCP
   requests and SHOULD listen for them on port 88 (decimal) unless
   specifically configured to listen on an alternate TCP port.
   Alternate ports MAY be used when running multiple KDCs for multiple
   realms on the same host.

   Clients MUST support the sending of TCP requests, but MAY choose to
   try a request initially using the UDP transport.  Clients SHOULD use
   KDC discovery [7.2.3] to identify the IP address and port to which
   they will send their request.

   Implementation note: Some extensions to the Kerberos protocol will
   not succeed if any client or KDC not supporting the TCP transport is
   involved.  Implementations of RFC 1510 were not required to support
   TCP/IP transports.

   When the KRB_KDC_REQ message is sent to the KDC over a TCP stream,
   the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to
   the client on the same TCP stream that was established for the
   request.  The KDC MAY close the TCP stream after sending a response,
   but MAY leave the stream open for a reasonable period of time if it
   expects a follow-up.  Care must be taken in managing TCP/IP
   connections on the KDC to prevent denial of service attacks based on
   the number of open TCP/IP connections.

   The client MUST be prepared to have the stream closed by the KDC at
   any time after the receipt of a response.  A stream closure SHOULD
   NOT be treated as a fatal error.  Instead, if multiple exchanges are
   required (e.g., certain forms of pre-authentication), the client may
   need to establish a new connection when it is ready to send

   subsequent messages.  A client MAY close the stream after receiving a
   response, and SHOULD close the stream if it does not expect to send
   follow-up messages.

   A client MAY send multiple requests before receiving responses,
   though it must be prepared to handle the connection being closed
   after the first response.

   Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR)
   sent over the TCP stream is preceded by the length of the request as
   4 octets in network byte order.  The high bit of the length is
   reserved for future expansion and MUST currently be set to zero.  If
   a KDC that does not understand how to interpret a set high bit of the
   length encoding receives a request with the high order bit of the
   length set, it MUST return a KRB-ERROR message with the error
   KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream.

   If multiple requests are sent over a single TCP connection and the
   KDC sends multiple responses, the KDC is not required to send the
   responses in the order of the corresponding requests.  This may
   permit some implementations to send each response as soon as it is
   ready, even if earlier requests are still being processed (for
   example, waiting for a response from an external device or database).

7.2.3.  KDC Discovery on IP Networks

   Kerberos client implementations MUST provide a means for the client
   to determine the location of the Kerberos Key Distribution Centers
   (KDCs).  Traditionally, Kerberos implementations have stored such
   configuration information in a file on each client machine.
   Experience has shown that this method of storing configuration
   information presents problems with out-of-date information and
   scaling, especially when using cross-realm authentication.  This
   section describes a method for using the Domain Name System [RFC1035]
   for storing KDC location information.

7.2.3.1.  DNS vs. Kerberos: Case Sensitivity of Realm Names

   In Kerberos, realm names are case sensitive.  Although it is strongly
   encouraged that all realm names be all uppercase, this recommendation
   has not been adopted by all sites.  Some sites use all lowercase
   names and other use mixed case.  DNS, on the other hand, is case
   insensitive for queries.  Because the realm names "MYREALM",
   "myrealm", and "MyRealm" are all different, but resolve the same in
   the domain name system, it is necessary that only one of the possible
   combinations of upper- and lowercase characters be used in realm
   names.

7.2.3.2.  Specifying KDC Location Information with DNS SRV records

   KDC location information is to be stored using the DNS SRV RR
   [RFC2782].  The format of this RR is as follows:

      _Service._Proto.Realm TTL Class SRV Priority Weight Port Target

   The Service name for Kerberos is always "kerberos".

   The Proto can be either "udp" or "tcp".  If these SRV records are to
   be used, both "udp" and "tcp" records MUST be specified for all KDC
   deployments.

   The Realm is the Kerberos realm that this record corresponds to.  The
   realm MUST be a domain-style realm name.

   TTL, Class, SRV, Priority, Weight, and Target have the standard
   meaning as defined in RFC 2782.

   As per RFC 2782, the Port number used for "_udp" and "_tcp" SRV
   records SHOULD be the value assigned to "kerberos" by the Internet
   Assigned Number Authority: 88 (decimal), unless the KDC is configured
   to listen on an alternate TCP port.

   Implementation note: Many existing client implementations do not
   support KDC Discovery and are configured to send requests to the IANA
   assigned port (88 decimal), so it is strongly recommended that KDCs
   be configured to listen on that port.

7.2.3.3.  KDC Discovery for Domain Style Realm Names on IP Networks

   These are DNS records for a Kerberos realm EXAMPLE.COM.  It has two
   Kerberos servers, kdc1.example.com and kdc2.example.com.  Queries
   should be directed to kdc1.example.com first as per the specified
   priority.  Weights are not used in these sample records.

     _kerberos._udp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
     _kerberos._udp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.
     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   0 0 88 kdc1.example.com.
     _kerberos._tcp.EXAMPLE.COM.     IN   SRV   1 0 88 kdc2.example.com.

7.3.  Name of the TGS

   The principal identifier of the ticket-granting service shall be
   composed of three parts: the realm of the KDC issuing the TGS ticket,
   and a two-part name of type NT-SRV-INST, with the first part "krbtgt"
   and the second part the name of the realm that will accept the TGT.
   For example, a TGT issued by the ATHENA.MIT.EDU realm to be used to

   get tickets from the ATHENA.MIT.EDU KDC has a principal identifier of
   "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name).  A TGT
   issued by the ATHENA.MIT.EDU realm to be used to get tickets from the
   MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm),
   ("krbtgt", "MIT.EDU") (name).

7.4.  OID Arc for KerberosV5

   This OID MAY be used to identify Kerberos protocol messages
   encapsulated in other protocols.  It also designates the OID arc for
   KerberosV5-related OIDs assigned by future IETF action.
   Implementation note: RFC 1510 had an incorrect value (5) for "dod" in
   its OID.

   id-krb5         OBJECT IDENTIFIER ::= {
           iso(1) identified-organization(3) dod(6) internet(1)
           security(5) kerberosV5(2)
   }

   Assignment of OIDs beneath the id-krb5 arc must be obtained by
   contacting the registrar for the id-krb5 arc, or its designee.  At
   the time of the issuance of this RFC, such registrations can be
   obtained by contacting krb5-oid-registrar@mit.edu.

7.5.  Protocol Constants and Associated Values

   The following tables list constants used in the protocol and define
   their meanings.  In the "specification" section, ranges are specified
   that limit the values of constants for which values are defined here.
   This allows implementations to make assumptions about the maximum
   values that will be received for these constants.  Implementations
   receiving values outside the range specified in the "specification"
   section MAY reject the request, but they MUST recover cleanly.

7.5.1.  Key Usage Numbers

   The encryption and checksum specifications in [RFC3961] require as
   input a "key usage number", to alter the encryption key used in any
   specific message in order to make certain types of cryptographic
   attack more difficult.  These are the key usage values assigned in
   this document:

           1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with
               the client key (Section 5.2.7.2)

           2.  AS-REP Ticket and TGS-REP Ticket (includes TGS session
               key or application session key), encrypted with the
               service key (Section 5.3)
           3.  AS-REP encrypted part (includes TGS session key or
               application session key), encrypted with the client key
               (Section 5.4.2)
           4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
               the TGS session key (Section 5.4.1)
           5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with
               the TGS authenticator subkey (Section 5.4.1)
           6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum,
               keyed with the TGS session key (Section 5.5.1)
           7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes
               TGS authenticator subkey), encrypted with the TGS session
               key (Section 5.5.1)
           8.  TGS-REP encrypted part (includes application session
               key), encrypted with the TGS session key (Section 5.4.2)
           9.  TGS-REP encrypted part (includes application session
               key), encrypted with the TGS authenticator subkey
               (Section 5.4.2)
          10.  AP-REQ Authenticator cksum, keyed with the application
               session key (Section 5.5.1)
          11.  AP-REQ Authenticator (includes application authenticator
               subkey), encrypted with the application session key
               (Section 5.5.1)
          12.  AP-REP encrypted part (includes application session
               subkey), encrypted with the application session key
               (Section 5.5.2)
          13.  KRB-PRIV encrypted part, encrypted with a key chosen by
               the application (Section 5.7.1)
          14.  KRB-CRED encrypted part, encrypted with a key chosen by
               the application (Section 5.8.1)
          15.  KRB-SAFE cksum, keyed with a key chosen by the
               application (Section 5.6.1)
       16-18.  Reserved for future use in Kerberos and related
               protocols.
          19.  AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4)
       20-21.  Reserved for future use in Kerberos and related
               protocols.
       22-25.  Reserved for use in the Kerberos Version 5 GSS-API
               mechanisms [RFC4121].
      26-511.  Reserved for future use in Kerberos and related
               protocols.
    512-1023.  Reserved for uses internal to a Kerberos implementation.
        1024.  Encryption for application use in protocols that do not
               specify key usage values

        1025.  Checksums for application use in protocols that do not
               specify key usage values
   1026-2047.  Reserved for application use.

7.5.2.  PreAuthentication Data Types

   Padata and Data Type    Padata-type   Comment
                            Value

   PA-TGS-REQ                  1
   PA-ENC-TIMESTAMP            2
   PA-PW-SALT                  3
   [reserved]                  4
   PA-ENC-UNIX-TIME            5        (deprecated)
   PA-SANDIA-SECUREID          6
   PA-SESAME                   7
   PA-OSF-DCE                  8
   PA-CYBERSAFE-SECUREID       9
   PA-AFS3-SALT                10
   PA-ETYPE-INFO               11
   PA-SAM-CHALLENGE            12       (sam/otp)
   PA-SAM-RESPONSE             13       (sam/otp)
   PA-PK-AS-REQ_OLD            14       (pkinit)
   PA-PK-AS-REP_OLD            15       (pkinit)
   PA-PK-AS-REQ                16       (pkinit)
   PA-PK-AS-REP                17       (pkinit)
   PA-ETYPE-INFO2              19       (replaces pa-etype-info)
   PA-USE-SPECIFIED-KVNO       20
   PA-SAM-REDIRECT             21       (sam/otp)
   PA-GET-FROM-TYPED-DATA      22       (embedded in typed data)
   TD-PADATA                   22       (embeds padata)
   PA-SAM-ETYPE-INFO           23       (sam/otp)
   PA-ALT-PRINC                24       (crawdad@fnal.gov)
   PA-SAM-CHALLENGE2           30       (kenh@pobox.com)
   PA-SAM-RESPONSE2            31       (kenh@pobox.com)
   PA-EXTRA-TGT                41       Reserved extra TGT
   TD-PKINIT-CMS-CERTIFICATES  101      CertificateSet from CMS
   TD-KRB-PRINCIPAL            102      PrincipalName
   TD-KRB-REALM                103      Realm
   TD-TRUSTED-CERTIFIERS       104      from PKINIT
   TD-CERTIFICATE-INDEX        105      from PKINIT
   TD-APP-DEFINED-ERROR        106      application specific
   TD-REQ-NONCE                107      INTEGER
   TD-REQ-SEQ                  108      INTEGER
   PA-PAC-REQUEST              128      (jbrezak@exchange.microsoft.com)

7.5.3.  Address Types

   Address Type                   Value

   IPv4                             2
   Directional                      3
   ChaosNet                         5
   XNS                              6
   ISO                              7
   DECNET Phase IV                 12
   AppleTalk DDP                   16
   NetBios                         20
   IPv6                            24

7.5.4.  Authorization Data Types

   Authorization Data Type          Ad-type Value

   AD-IF-RELEVANT                     1
   AD-INTENDED-FOR-SERVER             2
   AD-INTENDED-FOR-APPLICATION-CLASS  3
   AD-KDC-ISSUED                      4
   AD-AND-OR                          5
   AD-MANDATORY-TICKET-EXTENSIONS     6
   AD-IN-TICKET-EXTENSIONS            7
   AD-MANDATORY-FOR-KDC               8
   Reserved values                 9-63
   OSF-DCE                           64
   SESAME                            65
   AD-OSF-DCE-PKI-CERTID             66 (hemsath@us.ibm.com)
   AD-WIN2K-PAC                     128 (jbrezak@exchange.microsoft.com)
   AD-ETYPE-NEGOTIATION             129  (lzhu@windows.microsoft.com)

7.5.5.  Transited Encoding Types

   Transited Encoding Type         Tr-type Value

   DOMAIN-X500-COMPRESS            1
   Reserved values                 All others

7.5.6.  Protocol Version Number

   Label               Value   Meaning or MIT Code

   pvno                  5     Current Kerberos protocol version number

7.5.7.  Kerberos Message Types

   Message Type   Value  Meaning

   KRB_AS_REQ      10    Request for initial authentication
   KRB_AS_REP      11    Response to KRB_AS_REQ request
   KRB_TGS_REQ     12    Request for authentication based on TGT
   KRB_TGS_REP     13    Response to KRB_TGS_REQ request
   KRB_AP_REQ      14    Application request to server
   KRB_AP_REP      15    Response to KRB_AP_REQ_MUTUAL
   KRB_RESERVED16  16    Reserved for user-to-user krb_tgt_request
   KRB_RESERVED17  17    Reserved for user-to-user krb_tgt_reply
   KRB_SAFE        20    Safe (checksummed) application message
   KRB_PRIV        21    Private (encrypted) application message
   KRB_CRED        22    Private (encrypted) message to forward
                           credentials
   KRB_ERROR       30    Error response

7.5.8.  Name Types

   Name Type           Value  Meaning

   KRB_NT_UNKNOWN        0    Name type not known
   KRB_NT_PRINCIPAL      1    Just the name of the principal as in DCE,
                                or for users
   KRB_NT_SRV_INST       2    Service and other unique instance (krbtgt)
   KRB_NT_SRV_HST        3    Service with host name as instance
                                (telnet, rcommands)
   KRB_NT_SRV_XHST       4    Service with host as remaining components
   KRB_NT_UID            5    Unique ID
   KRB_NT_X500_PRINCIPAL 6    Encoded X.509 Distinguished name [RFC2253]
   KRB_NT_SMTP_NAME      7    Name in form of SMTP email name
                                (e.g., user@example.com)
   KRB_NT_ENTERPRISE    10    Enterprise name; may be mapped to
                                principal name

7.5.9.  Error Codes

   Error Code                         Value  Meaning

   KDC_ERR_NONE                           0  No error
   KDC_ERR_NAME_EXP                       1  Client's entry in database
                                               has expired
   KDC_ERR_SERVICE_EXP                    2  Server's entry in database
                                               has expired
   KDC_ERR_BAD_PVNO                       3  Requested protocol version
                                               number not supported

   KDC_ERR_C_OLD_MAST_KVNO                4  Client's key encrypted in
                                               old master key
   KDC_ERR_S_OLD_MAST_KVNO                5  Server's key encrypted in
                                               old master key
   KDC_ERR_C_PRINCIPAL_UNKNOWN            6  Client not found in
                                               Kerberos database
   KDC_ERR_S_PRINCIPAL_UNKNOWN            7  Server not found in
                                               Kerberos database
   KDC_ERR_PRINCIPAL_NOT_UNIQUE           8  Multiple principal entries
                                               in database
   KDC_ERR_NULL_KEY                       9  The client or server has a
                                               null key
   KDC_ERR_CANNOT_POSTDATE               10  Ticket not eligible for
                                               postdating
   KDC_ERR_NEVER_VALID                   11  Requested starttime is
                                               later than end time
   KDC_ERR_POLICY                        12  KDC policy rejects request
   KDC_ERR_BADOPTION                     13  KDC cannot accommodate
                                               requested option
   KDC_ERR_ETYPE_NOSUPP                  14  KDC has no support for
                                               encryption type
   KDC_ERR_SUMTYPE_NOSUPP                15  KDC has no support for
                                               checksum type
   KDC_ERR_PADATA_TYPE_NOSUPP            16  KDC has no support for
                                               padata type
   KDC_ERR_TRTYPE_NOSUPP                 17  KDC has no support for
                                               transited type
   KDC_ERR_CLIENT_REVOKED                18  Clients credentials have
                                               been revoked
   KDC_ERR_SERVICE_REVOKED               19  Credentials for server have
                                               been revoked
   KDC_ERR_TGT_REVOKED                   20  TGT has been revoked
   KDC_ERR_CLIENT_NOTYET                 21  Client not yet valid; try
                                               again later
   KDC_ERR_SERVICE_NOTYET                22  Server not yet valid; try
                                               again later
   KDC_ERR_KEY_EXPIRED                   23  Password has expired;
                                               change password to reset
   KDC_ERR_PREAUTH_FAILED                24  Pre-authentication
                                               information was invalid
   KDC_ERR_PREAUTH_REQUIRED              25  Additional pre-
                                               authentication required
   KDC_ERR_SERVER_NOMATCH                26  Requested server and ticket
                                               don't match
   KDC_ERR_MUST_USE_USER2USER            27  Server principal valid for
                                               user2user only
   KDC_ERR_PATH_NOT_ACCEPTED             28  KDC Policy rejects
                                               transited path

   KDC_ERR_SVC_UNAVAILABLE               29  A service is not available
   KRB_AP_ERR_BAD_INTEGRITY              31  Integrity check on
                                               decrypted field failed
   KRB_AP_ERR_TKT_EXPIRED                32  Ticket expired
   KRB_AP_ERR_TKT_NYV                    33  Ticket not yet valid
   KRB_AP_ERR_REPEAT                     34  Request is a replay
   KRB_AP_ERR_NOT_US                     35  The ticket isn't for us
   KRB_AP_ERR_BADMATCH                   36  Ticket and authenticator
                                               don't match
   KRB_AP_ERR_SKEW                       37  Clock skew too great
   KRB_AP_ERR_BADADDR                    38  Incorrect net address
   KRB_AP_ERR_BADVERSION                 39  Protocol version mismatch
   KRB_AP_ERR_MSG_TYPE                   40  Invalid msg type
   KRB_AP_ERR_MODIFIED                   41  Message stream modified
   KRB_AP_ERR_BADORDER                   42  Message out of order
   KRB_AP_ERR_BADKEYVER                  44  Specified version of key is
                                               not available
   KRB_AP_ERR_NOKEY                      45  Service key not available
   KRB_AP_ERR_MUT_FAIL                   46  Mutual authentication
                                               failed
   KRB_AP_ERR_BADDIRECTION               47  Incorrect message direction
   KRB_AP_ERR_METHOD                     48  Alternative authentication
                                               method required
   KRB_AP_ERR_BADSEQ                     49  Incorrect sequence number
                                               in message
   KRB_AP_ERR_INAPP_CKSUM                50  Inappropriate type of
                                               checksum in message
   KRB_AP_PATH_NOT_ACCEPTED              51  Policy rejects transited
                                               path
   KRB_ERR_RESPONSE_TOO_BIG              52  Response too big for UDP;
                                               retry with TCP
   KRB_ERR_GENERIC                       60  Generic error (description
                                               in e-text)
   KRB_ERR_FIELD_TOOLONG                 61  Field is too long for this
                                               implementation
   KDC_ERROR_CLIENT_NOT_TRUSTED          62  Reserved for PKINIT
   KDC_ERROR_KDC_NOT_TRUSTED             63  Reserved for PKINIT
   KDC_ERROR_INVALID_SIG                 64  Reserved for PKINIT
   KDC_ERR_KEY_TOO_WEAK                  65  Reserved for PKINIT
   KDC_ERR_CERTIFICATE_MISMATCH          66  Reserved for PKINIT
   KRB_AP_ERR_NO_TGT                     67  No TGT available to
                                               validate USER-TO-USER
   KDC_ERR_WRONG_REALM                   68  Reserved for future use
   KRB_AP_ERR_USER_TO_USER_REQUIRED      69  Ticket must be for
                                               USER-TO-USER
   KDC_ERR_CANT_VERIFY_CERTIFICATE       70  Reserved for PKINIT
   KDC_ERR_INVALID_CERTIFICATE           71  Reserved for PKINIT
   KDC_ERR_REVOKED_CERTIFICATE           72  Reserved for PKINIT

   KDC_ERR_REVOCATION_STATUS_UNKNOWN     73  Reserved for PKINIT
   KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74  Reserved for PKINIT
   KDC_ERR_CLIENT_NAME_MISMATCH          75  Reserved for PKINIT
   KDC_ERR_KDC_NAME_MISMATCH             76  Reserved for PKINIT

8.  Interoperability Requirements

   Version 5 of the Kerberos protocol supports a myriad of options.
   Among these are multiple encryption and checksum types; alternative
   encoding schemes for the transited field; optional mechanisms for
   pre-authentication; the handling of tickets with no addresses;
   options for mutual authentication; user-to-user authentication;
   support for proxies; the format of realm names; the handling of
   authorization data; and forwarding, postdating, and renewing tickets.

   In order to ensure the interoperability of realms, it is necessary to
   define a minimal configuration that must be supported by all
   implementations.  This minimal configuration is subject to change as
   technology does.  For example, if at some later date it is discovered
   that one of the required encryption or checksum algorithms is not
   secure, it will be replaced.

8.1.  Specification 2

   This section defines the second specification of these options.
   Implementations which are configured in this way can be said to
   support Kerberos Version 5 Specification 2 (5.2).  Specification 1
   (deprecated) may be found in RFC 1510.

   Transport

      TCP/IP and UDP/IP transport MUST be supported by clients and KDCs
      claiming conformance to specification 2.

   Encryption and Checksum Methods

      The following encryption and checksum mechanisms MUST be
      supported:

      Encryption: AES256-CTS-HMAC-SHA1-96 [RFC3962]
      Checksums: HMAC-SHA1-96-AES256 [RFC3962]

      Implementations SHOULD support other mechanisms as well, but the
      additional mechanisms may only be used when communicating with
      principals known to also support them.  The following mechanisms
      from [RFC3961] and [RFC3962] SHOULD be supported:

      Encryption: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD
      Checksums: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128

      Implementations MAY support other mechanisms as well, but the
      additional mechanisms may only be used when communicating with
      principals known to support them also.

      Implementation note: Earlier implementations of Kerberos generate
      messages using the CRC-32 and RSA-MD5 checksum methods.  For
      interoperability with these earlier releases, implementors MAY
      consider supporting these checksum methods but should carefully
      analyze the security implications to limit the situations within
      which these methods are accepted.

   Realm Names

      All implementations MUST understand hierarchical realms in both
      the Internet Domain and the X.500 style.  When a TGT for an
      unknown realm is requested, the KDC MUST be able to determine the
      names of the intermediate realms between the KDCs realm and the
      requested realm.

   Transited Field Encoding

      DOMAIN-X500-COMPRESS (described in Section 3.3.3.2) MUST be
      supported.  Alternative encodings MAY be supported, but they may
      only be used when that encoding is supported by ALL intermediate
      realms.

   Pre-authentication Methods

      The TGS-REQ method MUST be supported.  It is not used on the
      initial request.  The PA-ENC-TIMESTAMP method MUST be supported by
      clients, but whether it is enabled by default MAY be determined on
      a realm-by-realm basis.  If the method is not used in the initial
      request and the error KDC_ERR_PREAUTH_REQUIRED is returned
      specifying PA-ENC-TIMESTAMP as an acceptable method, the client
      SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-
      authentication method.  Servers need not support the PA-ENC-
      TIMESTAMP method, but if it is not supported the server SHOULD
      ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a
      request.

      The ETYPE-INFO2 method MUST be supported; this method is used to
      communicate the set of supported encryption types, and
      corresponding salt and string to key parameters.  The ETYPE-INFO
      method SHOULD be supported for interoperability with older
      implementation.

   Mutual Authentication

      Mutual authentication (via the KRB_AP_REP message) MUST be
      supported.

   Ticket Addresses and Flags

      All KDCs MUST pass through tickets that carry no addresses (i.e.,
      if a TGT contains no addresses, the KDC will return derivative
      tickets).  Implementations SHOULD default to requesting
      addressless tickets, as this significantly increases
      interoperability with network address translation.  In some cases,
      realms or application servers MAY require that tickets have an
      address.

      Implementations SHOULD accept directional address type for the
      KRB_SAFE and KRB_PRIV message and SHOULD include directional
      addresses in these messages when other address types are not
      available.

      Proxies and forwarded tickets MUST be supported.  Individual
      realms and application servers can set their own policy on when
      such tickets will be accepted.

      All implementations MUST recognize renewable and postdated
      tickets, but they need not actually implement them.  If these
      options are not supported, the starttime and endtime in the ticket
      SHALL specify a ticket's entire useful life.  When a postdated
      ticket is decoded by a server, all implementations SHALL make the
      presence of the postdated flag visible to the calling server.

   User-to-User Authentication

      Support for user-to-user authentication (via the ENC-TKT-IN-SKEY
      KDC option) MUST be provided by implementations, but individual
      realms MAY decide as a matter of policy to reject such requests on
      a per-principal or realm-wide basis.

   Authorization Data

      Implementations MUST pass all authorization data subfields from
      TGTs to any derivative tickets unless they are directed to
      suppress a subfield as part of the definition of that registered
      subfield type.  (It is never incorrect to pass on a subfield, and
      no registered subfield types presently specify suppression at the
      KDC.)

      Implementations MUST make the contents of any authorization data
      subfields available to the server when a ticket is used.
      Implementations are not required to allow clients to specify the
      contents of the authorization data fields.

   Constant Ranges

      All protocol constants are constrained to 32-bit (signed) values
      unless further constrained by the protocol definition.  This limit
      is provided to allow implementations to make assumptions about the
      maximum values that will be received for these constants.
      Implementations receiving values outside this range MAY reject the
      request, but they MUST recover cleanly.

8.2.  Recommended KDC Values

   Following is a list of recommended values for a KDC configuration.

      Minimum lifetime              5 minutes
      Maximum renewable lifetime    1 week
      Maximum ticket lifetime       1 day
      Acceptable clock skew         5 minutes
      Empty addresses               Allowed
      Proxiable, etc.               Allowed

9.  IANA Considerations

   Section 7 of this document specifies protocol constants and other
   defined values required for the interoperability of multiple
   implementations.  Until a subsequent RFC specifies otherwise, or the
   Kerberos working group is shut down, allocations of additional
   protocol constants and other defined values required for extensions
   to the Kerberos protocol will be administered by the Kerberos working
   group.  Following the recommendations outlined in [RFC2434], guidance
   is provided to the IANA as follows:

   "reserved" realm name types in Section 6.1 and "other" realm types
   except those beginning with "X-" or "x-" will not be registered
   without IETF standards action, at which point guidelines for further
   assignment will be specified.  Realm name types beginning with "X-"
   or "x-" are for private use.

   For host address types described in Section 7.1, negative values are
   for private use.  Assignment of additional positive numbers is
   subject to review by the Kerberos working group or other expert
   review.

   Additional key usage numbers, as defined in Section 7.5.1, will be
   assigned subject to review by the Kerberos working group or other
   expert review.

   Additional preauthentication data type values, as defined in section
   7.5.2, will be assigned subject to review by the Kerberos working
   group or other expert review.

   Additional authorization data types as defined in Section 7.5.4, will
   be assigned subject to review by the Kerberos working group or other
   expert review.  Although it is anticipated that there may be
   significant demand for private use types, provision is intentionally
   not made for a private use portion of the namespace because conflicts
   between privately assigned values could have detrimental security
   implications.

   Additional transited encoding types, as defined in Section 7.5.5,
   present special concerns for interoperability with existing
   implementations.  As such, such assignments will only be made by
   standards action, except that the Kerberos working group or another
   other working group with competent jurisdiction may make preliminary
   assignments for documents that are moving through the standards
   process.

   Additional Kerberos message types, as described in Section 7.5.7,
   will be assigned subject to review by the Kerberos working group or
   other expert review.

   Additional name types, as described in Section 7.5.8, will be
   assigned subject to review by the Kerberos working group or other
   expert review.

   Additional error codes described in Section 7.5.9 will be assigned
   subject to review by the Kerberos working group or other expert
   review.

10.  Security Considerations

   As an authentication service, Kerberos provides a means of verifying
   the identity of principals on a network.  By itself, Kerberos does
   not provide authorization.  Applications should not accept the
   issuance of a service ticket by the Kerberos server as granting
   authority to use the service, since such applications may become
   vulnerable to the bypass of this authorization check in an
   environment where they inter-operate with other KDCs or where other
   options for application authentication are provided.

   Denial of service attacks are not solved with Kerberos.  There are
   places in the protocols where an intruder can prevent an application
   from participating in the proper authentication steps.  Because
   authentication is a required step for the use of many services,
   successful denial of service attacks on a Kerberos server might
   result in the denial of other network services that rely on Kerberos
   for authentication.  Kerberos is vulnerable to many kinds of denial
   of service attacks: those on the network, which would prevent clients
   from contacting the KDC; those on the domain name system, which could
   prevent a client from finding the IP address of the Kerberos server;
   and those by overloading the Kerberos KDC itself with repeated
   requests.

   Interoperability conflicts caused by incompatible character-set usage
   (see 5.2.1) can result in denial of service for clients that utilize
   character-sets in Kerberos strings other than those stored in the KDC
   database.

   Authentication servers maintain a database of principals (i.e., users
   and servers) and their secret keys.  The security of the
   authentication server machines is critical.  The breach of security
   of an authentication server will compromise the security of all
   servers that rely upon the compromised KDC, and will compromise the
   authentication of any principals registered in the realm of the
   compromised KDC.

   Principals must keep their secret keys secret.  If an intruder
   somehow steals a principal's key, it will be able to masquerade as
   that principal or impersonate any server to the legitimate principal.

   Password-guessing attacks are not solved by Kerberos.  If a user
   chooses a poor password, it is possible for an attacker to
   successfully mount an off-line dictionary attack by repeatedly
   attempting to decrypt, with successive entries from a dictionary,
   messages obtained that are encrypted under a key derived from the
   user's password.

   Unless pre-authentication options are required by the policy of a
   realm, the KDC will not know whether a request for authentication
   succeeds.  An attacker can request a reply with credentials for any
   principal.  These credentials will likely not be of much use to the
   attacker unless it knows the client's secret key, but the
   availability of the response encrypted in the client's secret key
   provides the attacker with ciphertext that may be used to mount brute
   force or dictionary attacks to decrypt the credentials, by guessing
   the user's password.  For this reason it is strongly encouraged that
   Kerberos realms require the use of pre-authentication.  Even with

   pre-authentication, attackers may try brute force or dictionary
   attacks against credentials that are observed by eavesdropping on the
   network.

   Because a client can request a ticket for any server principal and
   can attempt a brute force or dictionary attack against the server
   principal's key using that ticket, it is strongly encouraged that
   keys be randomly generated (rather than generated from passwords) for
   any principals that are usable as the target principal for a
   KRB_TGS_REQ or KRB_AS_REQ messages.  [RFC4086]

   Although the DES-CBC-MD5 encryption method and DES-MD5 checksum
   methods are listed as SHOULD be implemented for backward
   compatibility, the single DES encryption algorithm on which these are
   based is weak, and stronger algorithms should be used whenever
   possible.

   Each host on the network must have a clock that is loosely
   synchronized to the time of the other hosts; this synchronization is
   used to reduce the bookkeeping needs of application servers when they
   do replay detection.  The degree of "looseness" can be configured on
   a per-server basis, but it is typically on the order of 5 minutes.
   If the clocks are synchronized over the network, the clock
   synchronization protocol MUST itself be secured from network
   attackers.

   Principal identifiers must not recycled on a short-term basis.  A
   typical mode of access control will use access control lists (ACLs)
   to grant permissions to particular principals.  If a stale ACL entry
   remains for a deleted principal and the principal identifier is
   reused, the new principal will inherit rights specified in the stale
   ACL entry.  By not reusing principal identifiers, the danger of
   inadvertent access is removed.

   Proper decryption of an KRB_AS_REP message from the KDC is not
   sufficient for the host to verify the identity of the user; the user
   and an attacker could cooperate to generate a KRB_AS_REP format
   message that decrypts properly but is not from the proper KDC.  To
   authenticate a user logging on to a local system, the credentials
   obtained in the AS exchange may first be used in a TGS exchange to
   obtain credentials for a local server.  Those credentials must then
   be verified by a local server through successful completion of the
   Client/Server exchange.

   Many RFC 1510-compliant implementations ignore unknown authorization
   data elements.  Depending on these implementations to honor
   authorization data restrictions may create a security weakness.

   Kerberos credentials contain clear-text information identifying the
   principals to which they apply.  If privacy of this information is
   needed, this exchange should itself be encapsulated in a protocol
   providing for confidentiality on the exchange of these credentials.

   Applications must take care to protect communications subsequent to
   authentication, either by using the KRB_PRIV or KRB_SAFE messages as
   appropriate, or by applying their own confidentiality or integrity
   mechanisms on such communications.  Completion of the KRB_AP_REQ and
   KRB_AP_REP exchange without subsequent use of confidentiality and
   integrity mechanisms provides only for authentication of the parties
   to the communication and not confidentiality and integrity of the
   subsequent communication.  Applications applying confidentiality and
   integrity protection mechanisms other than KRB_PRIV and KRB_SAFE must
   make sure that the authentication step is appropriately linked with
   the protected communication channel that is established by the
   application.

   Unless the application server provides its own suitable means to
   protect against replay (for example, a challenge-response sequence
   initiated by the server after authentication, or use of a server-
   generated encryption subkey), the server must utilize a replay cache
   to remember any authenticator presented within the allowable clock
   skew.  All services sharing a key need to use the same replay cache.
   If separate replay caches are used, then an authenticator used with
   one such service could later be replayed to a different service with
   the same service principal.

   If a server loses track of authenticators presented within the
   allowable clock skew, it must reject all requests until the clock
   skew interval has passed, providing assurance that any lost or
   replayed authenticators will fall outside the allowable clock skew
   and can no longer be successfully replayed.

   Implementations of Kerberos should not use untrusted directory
   servers to determine the realm of a host.  To allow this would allow
   the compromise of the directory server to enable an attacker to
   direct the client to accept authentication with the wrong principal
   (i.e., one with a similar name, but in a realm with which the
   legitimate host was not registered).

   Implementations of Kerberos must not use DNS to map one name to
   another (canonicalize) in order to determine the host part of the
   principal name with which one is to communicate.  To allow this
   canonicalization would allow a compromise of the DNS to result in a
   client obtaining credentials and correctly authenticating to the

   wrong principal.  Though the client will know who it is communicating
   with, it will not be the principal with which it intended to
   communicate.

   If the Kerberos server returns a TGT for a realm 'closer' than the
   desired realm, the client may use local policy configuration to
   verify that the authentication path used is an acceptable one.
   Alternatively, a client may choose its own authentication path rather
   than rely on the Kerberos server to select one.  In either case, any
   policy or configuration information used to choose or validate
   authentication paths, whether by the Kerberos server or client, must
   be obtained from a trusted source.

   The Kerberos protocol in its basic form does not provide perfect
   forward secrecy for communications.  If traffic has been recorded by
   an eavesdropper, then messages encrypted using the KRB_PRIV message,
   or messages encrypted using application-specific encryption under
   keys exchanged using Kerberos can be decrypted if the user's,
   application server's, or KDC's key is subsequently discovered.  This
   is because the session key used to encrypt such messages, when
   transmitted over the network, is encrypted in the key of the
   application server.  It is also encrypted under the session key from
   the user's TGT when it is returned to the user in the KRB_TGS_REP
   message.  The session key from the TGT is sent to the user in the
   KRB_AS_REP message encrypted in the user's secret key and embedded in
   the TGT, which was encrypted in the key of the KDC.  Applications
   requiring perfect forward secrecy must exchange keys through
   mechanisms that provide such assurance, but may use Kerberos for
   authentication of the encrypted channel established through such
   other means.

11.  Acknowledgements

   This document is a revision to RFC 1510 which was co-authored with
   John Kohl.  The specification of the Kerberos protocol described in
   this document is the result of many years of effort.  Over this
   period, many individuals have contributed to the definition of the
   protocol and to the writing of the specification.  Unfortunately, it
   is not possible to list all contributors as authors of this document,
   though there are many not listed who are authors in spirit, including
   those who contributed text for parts of some sections, who
   contributed to the design of parts of the protocol, and who
   contributed significantly to the discussion of the protocol in the
   IETF common authentication technology (CAT) and Kerberos working
   groups.

   Among those contributing to the development and specification of
   Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan
   Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl,
   Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn,
   Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome
   Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift,
   Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar
   Westerlund, and Nicolas Williams.  Many other members of MIT Project
   Athena, the MIT networking group, and the Kerberos and CAT working
   groups of the IETF contributed but are not listed.