Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4120

The Kerberos Network Authentication Service (V5)

Pages: 138
Proposed Standard
Errata
Obsoletes:  1510
Updated by:  4537502158966111611261136649680677518062812984298553
Part 5 of 6 – Pages 101 to 122
First   Prev   Next

Top   ToC   RFC4120 - Page 101   prevText

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).
Top   ToC   RFC4120 - Page 102
   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.
Top   ToC   RFC4120 - Page 103
   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
Top   ToC   RFC4120 - Page 104
   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.
Top   ToC   RFC4120 - Page 105
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
Top   ToC   RFC4120 - Page 106
   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)
Top   ToC   RFC4120 - Page 107
           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
Top   ToC   RFC4120 - Page 108
        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)
Top   ToC   RFC4120 - Page 109

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
Top   ToC   RFC4120 - Page 110

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
Top   ToC   RFC4120 - Page 111
   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
Top   ToC   RFC4120 - Page 112
   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
Top   ToC   RFC4120 - Page 113
   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:
Top   ToC   RFC4120 - Page 114
      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.
Top   ToC   RFC4120 - Page 115
   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.)
Top   ToC   RFC4120 - Page 116
      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.
Top   ToC   RFC4120 - Page 117
   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.
Top   ToC   RFC4120 - Page 118
   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
Top   ToC   RFC4120 - Page 119
   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.
Top   ToC   RFC4120 - Page 120
   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
Top   ToC   RFC4120 - Page 121
   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.
Top   ToC   RFC4120 - Page 122
   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.