Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
Extracted elements (14)
A Kerberos authenticator is not required for replay protection because the master secret derivation is seeded with a random value from the ServerHello message, which already prevents replay attacks. The authenticator field is retained as optional to allow passing authorization information.
Mutual authentication is achieved without adding any new TLS messages: the TLS server proves knowledge of the master secret in the Finished message, and the client's Kerberos credentials authenticate the client to the server implicitly through the ticket.
The Kerberos authentication option is designed to fit into TLS exactly as a new public key algorithm would, establishing the master secret in the same manner. This minimizes changes to the TLS framework while enabling symmetric-key-based authentication for organizations with heterogeneous security deployments.
The Kerberos ticket and authenticator are encoded using ASN.1 encoding as specified in RFC 1510. Implementations must follow RFC 1510 encoding rules for these fields within the KerberosWrapper.
To establish a Kerberos-based security context, one or more of the defined Kerberos cipher suites MUST be specified in the ClientHello message.
Fourteen new TLS cipher suites are defined to support Kerberos-based authentication, with code points 0x001E through 0x002B. These include variants using DES-CBC, 3DES-EDE-CBC, RC4-128, and IDEA-CBC with SHA or MD5 MACs, plus six 40-bit export-grade suites.
The ClientKeyExchange message is extended with a new 'krb5' case in its KeyExchangeAlgorithm select, carrying a KerberosWrapper instead of an EncryptedPreMasterSecret or ClientDiffieHellmanPublic.
The pre-master secret used with Kerberos authentication is the same 48-byte random structure as in the RSA case. It is encrypted under the Kerberos session key and transmitted to the server inside KerberosWrapper alongside the Kerberos credentials.
To obtain a service ticket, the TLS client uses the Kerberos naming convention 'host/MachineName@Realm', where 'host' is the literal service name, 'MachineName' is the server instance, and 'Realm' is the DNS domain name of the machine.
When a Kerberos cipher suite is selected, the server's Certificate, CertificateRequest, and ServerKeyExchange messages are omitted from the TLS handshake, as is the client Certificate message. These are all optional in TLS, so omitting them is permissible.
This document registers 14 TLS cipher suite code points (0x00,0x1E through 0x00,0x2B) for Kerberos-based cipher suites, covering combinations of DES-CBC, 3DES-EDE-CBC, RC4-128, IDEA-CBC, RC2-CBC-40, RC4-40, and DES-CBC-40 with SHA or MD5.
A Kerberos implementation must protect the long-lived secret shared between the principal and the KDC. A weak password may be subject to a dictionary attack; implementors may use secondary authentication (e.g., token card) or PKINIT (public-key-based initial KDC authentication) to strengthen security.
The 40-bit export cipher suites (TLS_KRB5_EXPORT_*) defined in this document are included solely to document already-assigned code points. They were designed for now-obsolete US export restrictions, were never secure, and their implementation and use is strongly discouraged.
The KerberosWrapper structure embedded in ClientKeyExchange contains three opaque fields: a Kerberos Ticket, an optional authenticator, and an EncryptedPreMasterSecret encrypted with the Kerberos session key sealed in the ticket. Ticket and authenticator are ASN.1-encoded per RFC 1510.