Shishi is able to “upgrade” TCP communications with the KDC to use the Transport Layer Security (TLS) protocol. The TLS protocol offers integrity and privacy protected exchanges. TLS also offers authentication using username and passwords, X.509 certificates, or OpenPGP certificates. Kerberos 5 claims to offer some of these features, although it is not as rich as the TLS protocol. An inconclusive list of the motivation for using TLS is given below.
Other reasons for using TLS exists.
RFC 1510bis requires Kerberos servers (KDCs) to accept TCP requests.
Each request and response is prefixed by a 4 octet integer in network
byte order, indicating the length of the packet. The high bit of the
length was reserved for future expansion, and servers that do not
understand how to interpret a set high bit must return a
KRB-ERROR with a
KRB_ERR_FIELD_TOOLONG and close the TCP
The TCP/IP transport with TLS upgrade (STARTTLS) uses this reserved bit as follows. First we define a new extensible typed hole for Kerberos 5 messages, because we used the only reserved bit. It is thus prudent to offer future extensions on our proposal. Secondly we reserve two values in this new typed hole, and described how they are used to implement STARTTLS.
When the high bit is set, the remaining 31 bits of the 4 octets are
treated as an extensible typed hole, and thus form a 31 bit integer
enumerating various extensions. Each of the values indicate a
specific extended operation mode, two of which are used and defined
here, and the rest are left for others to use. If the KDC do not
understand a requested extension, it MUST return a
KRB_ERR_FIELD_TOOLONG value (prefixed by the 4 octet
length integer, with the high bit clear, as usual) and close the TCP
Meaning of the 31 lower bits in the 4 octet field, when the high bit is set:
0 RESERVED. 1 STARTTLS requested by client. 2 STARTTLS request accepted by server. 3...2147483647 AVAILABLE for registration (via firstname.lastname@example.org). 2147483648 RESERVED.
When this is sent by the client, the client is requesting the server to start TLS negotiation on the TCP stream. The client MUST NOT start TLS negotiation immediately. Instead, the client wait for either a KRB-ERROR (sent normally, prefixed by a 4 octet length integer) indicating the server do not understand the set high bit, or 4 octet which is to interpreted as an integer in network byte order, where the high bit is set and the remaining 31 bit are interpreted as an integer specifying the “STARTTLS request accepted by server”. In the first case, the client infer that the server do not understand (or wish to support) STARTTLS, and can re-try using normal TCP, if unprotected Kerberos 5 exchanges are acceptable to the client policy. In the latter case, it should invoke TLS negotiation on the stream. If any other data is received, the client MUST close the TCP stream.
This 4 octet message should be sent by the server when it has received the previous 4 octet message. The message is an acknowledgment of the client's request to initiate STARTTLS on the channel. The server MUST then invoke a TLS negotiation.
If the TLS negotiation ended successfully, possibly also considering client or server policies, the exchange within the TLS protected stream is performed like normal UDP Kerberos 5 exchanges, i.e., there is no TCP 4 octet length field before each packet. Instead each Kerberos packet MUST be sent within one TLS record, so the application can use the TLS record length as the Kerberos 5 packet length.
If the TLS negotiation fails, possibly due to client or server policy (e.g., inadequate support of encryption types in TLS, or lack of client or server authentication) the entity that detect the failure MUST disconnected the connection. It is expected that any error messages that explain the error condition is transfered by TLS.
Administrators for a KDC may announce the KDC address by placing SRV records in DNS for the realm, as described in draft-ietf-krb-wg-krb-dns-locate-03.txt. That document mention TLS, but do not reference any work that describe how KDCs uses TLS. Until further clarified, consider the TLS field in that document to refer to implementation supporting this STARTTLS protocol.
The server MAY consider the authentication performed by the TLS exchange as sufficient to issue Kerberos 5 tickets to the client, without requiring, e.g., pre-authentication. However, it is not an error to require or use pre-authentication as well.
The client may also indicate that it wishes to use TLS both for authentication and data protection by using the ‘NULL’ encryption type in its request. The server can decide from its local policy whether or not issuing tickets based solely on TLS authentication, and whether ‘NULL’ encryption within TLS, is acceptable or not. This mode is currently under investigation.
Because the initial token is not protected, it is possible for an active attacker to make it appear to the client that the server do not support this extension. It is up to client configuration to disallow non-TLS connections, if this vulnerability is deemed unacceptable. For interoperability, we suggest the default behaviour should be to allow automatic fallback to TCP or UDP.
The security considerations of both TLS and Kerberos 5 are inherited. Using TLS for authentication and/or data protection together with Kerberos alter the authentication logic fundamentally. Thus, it may be that even if the TLS and Kerberos 5 protocols and implementations were secure, the combination of TLS and Kerberos 5 described here could be insecure.
No channel bindings are provided in the Kerberos messages. It is an open question whether, and how, this should be fixed.