This specification extends TLS with a GSSAPI-based method of client authentication. This can be used to facilitate TLS as a general mechanism between Kerberos5 principals.

Non-normative Rationale: http://rickywiki.vanrein.org/doku.php?id=tls-6-kerberos

Introduction

GSSAPI is commonly used to embed Kerberos5 exchanges in other protocols. Its interface is more generic than Kerberos5 alone, and although this specification follows that general approach it is likely that it will in practice be used only for Kerberos5. As a result, Kerberos5 tickets are the most common instance of what GSSAPI calls credentials.

Kerberos5 is intruiging because it is integrated into many protocols, but an integration into TLS could be so generic that many applications could delegate authentication to this “external” layer.

The very popular HTTP protocol can carry GSSAPI credentials in the SPNEGO authentication exchange. Although this permits the exchange of Kerberos tickets, it has a few drawbacks.

  • The server demands SPNEGO from a client without knowing if another authentication method could be more suitable;

  • Without the extra work of a challenge/response exchange over HTTP the server cannot detect MITM attacks; this involves a complete resent of the original request, including any bodies that it may have carried;

  • The SPNEGO credentials are cryptographically detached from the session, and even from the HTTP request that surrounds it; a ticket is not used to derive session encryption secrets, so assumptions on the authenticity of transmitted data can at best be inferred from the transport layer protocol.

  • TODO: Need for whitelisting — why? is it meant to offload the KDC from spurious requests? if so, does the realm names list help?

When based on this specification, HTTPS can be used without the drawbacks of SPNEGO. TLS extensions exchange whether GSSAPI is available for client authentication, the exchange takes place before application_data is exchanged and the GSSAPI secrets are cryptographically bound to the TLS session.

A GSSAPI credential is a public entity, and does not prove anything by itself. It carries a session key that can only be used by a client and a service. To use it, information can be “wrapped” and “unwrapped” only by these two principals. The TLS extension specified here uses this privileged wrapping facility to construct a part of the TLS Master Secret, so as to establish a mutual proof of identity.

A tricky part of approach a service is how to locate its ticket. To simplify this operation, the protocol extension exchanges hints in the form of realm names that support the requested service name. The realm names can help the client to select a principal name to use, as well as to look for a service ticket with its own KDC.

New CipherSuites for GSSAPI

This specification extends TLS [RFC 5246] with a number of CiperSuites that incorporate GSSAPI credentials. These are listed in the Section with IANA Considerations.

The names of CipherSuites implementing GSSAPI but not ephemeral Diffie-Hellman start with:

TLS_GSSAPI_WITH_

The names of CipherSuites that implement GSSAPI with ephemeral Diffie-Hellman start with:

TLS_DHE_GSSAPI_WITH_
TLS_ECDHE_GSSAPI_WITH_

It is generally advised to combine Kerberos5 authentication with a form of Diffie-Hellman. This is because a cracked client password can very well be used to decode historically captured traffic. The first form is only advisable for secure renegotiation of a TLS connection which has established (anonymous) Diffie-Hellman.

ClientHello: Offering GSSAPI authentication

A client that is capable of GSSAPI authentication will offer one or more of the foregoing CipherSuites in its ClientHello message. Offering these is no guarantee that a server token has been found, but it expresses a willingness to look for one. TODO: Whitelisting

If the ClientHello includes the server_name extension [RFC 6066], and if that extension includes the HostName variant, then this will be the name that the client would use when looking for a service ticket. The protocol name is considered to be generally known. TODO: Register of protocol names?

ServerHello: Accepting GSSAPI authentication

When a client offers one of the GSSAPI CipherSuites defined above, the server may choose to authenticate it by choosing one of these CipherSuites. The client may succeed or fail; it is up to the server’s policy whether to continue with the client in case of failure. Similarly, the server’s policy determines how a client is handled if it does not offer any GSSAPI CipherSuites.

ServerKeyExchange: Offering DHE or ECDHE

When one of the TLS_DHE_GSSAPI_ or TLS_ECDHE_GSSAPI_ CipherSuites is selected, the ServerKeyExchange will include en ephemeral Diffie-Hellman offer. This is done through an extension of the ServerKeyExchange structure:

struct {
          select (KeyExchangeAlgorithm) {
              /* existing cases defined elsewhere */
              case gssapi:
                  struct { };
                  /* message is omitted for gssapi */
              case dhe_gssapi:
                  ServerDHParams params;
              case ecdhe_gssapi:
                  ServerECDHParams ec_params;
          };
      } ServerKeyExchange;

Note that the structures are not signed; instead of using a server certificate the Kerberos5 extension relies on the session key that Kerberos5 establishes between client and server, and from which a proof will be derived.

Listing realm names

The server may return a hint to the client, holding realm names under which its principal name can be used. The realm names are supplied for use with the assumed-known protocol name and the server name which is known to the client, and which it may have revealed in the server_name extension to the ClientHello.

In general, the server returns a list of realm names. It is possible for a server to provide similar services to multiple realms, and the ability to list realms is helpful to that end. It is advised to keep the list short, for example through the use of different hostnames for different realms.

The realm name list is a new TLS extension, and it is structured as follows:

TODO: Specify; see server_name, use a krb5realmnamelist tag.

Selecting a Client Credential

The service protocol, service name and the optional realm names list are hints to the client that helps to select one or more principal names. Several considerations could be taken into account by the client:

  • Local policy could specify a principal name to always use for a particular service protocol and/or service name and/or realm name;

  • A realm name match with a principal ticket’s realm could suggest using that;

  • Mere availability of a service ticket could suggest using the holding principal;

  • Mere availability of a principal ticket could suggest using that.

Given a selection and possible ordering of principal names to consider, the local client can now attempt to acquire a service ticket, and use it to proceed.

If no service ticket can be acquired, none will be sent. It will then be up to the server whether this is considered acceptable.

ClientKeyExchange: Offering a GSSAPI credential

The ClientKeyExchange can take a number of forms, depending on whether it found a service ticket and whether adding DHE or ECDHE or not. When no service ticket is found, this is reflected in an empty GSSAPI byte stream, and the other alternatives are defined by the CipherSuite:

struct {
     select (KeyExchangeAlgorithm) {
         /* existing cases defined elsewhere */
         case gssapi:
         case dhe_gssapi:
         case ecdhe_gssapi:
             opaque gssapi_cred<0..2^16-1>;
             select (KeyExchangeAlgorithm) {
                 case gssapi:
                     struct { };
                 case dhe_gssapi:
                     ClientDiffieHellmanPublic;
                 case ecdhe_gssapi:
                     ClientECDiffieHellmanPublic;
             } exchange_keys_gssapi;
     } exchange_keys;
} ClientKeyExchange;

The opaque gssapi_cred string holds the literal bytes output by the GSSAPI call GSS_Init_sec_context() [RFC 2743]. TLS carries the bytes in binary form, without mapping it to a printable form such as base64.

Master Secret Calculation

The procedure of calculating of the master secret from the pre-master secret remains unchanged. Only the composition of the pre-master secret is specific for the CipherSuites introduced in this specification.

The GSSAPI Credential holds a session key, which is privileged information to the authentic client and authentic server; we follow the habit of trusting the KDC (or path of KDCs) connecting the client and server.

To use this session key, GSSAPI can wrap information, which usually means encrypting it. The information to wrap is ClientHello.random + ServerHello.random, a sequence of 64 bytes. The outcome of the wrapping operation may be somewhat longer. This outcome will be denoted as X.

For dhe_gssapi, the negotiated key Z will be used, after stripping initial bytes with zero value; we will call this value Y.

For ecdhe_gssapi, the negotiated key Z will be used; we will call this value Y.

For gssapi, the empty string will be called Y.

The pre-master secret is now composed of the concatenation of

  • a 2-byte value encoding the length of X;

  • the byte string of X;

  • a 2-byte value encoding the length of Y;

  • the byte string of Y.

In all cases, but specifically of interest for gssapi, any previously established security parameters are available during secure renegotiation, and will be hashed into the upcoming Finished message.

Finished: Mutual Validation

The security of GSSAPI relies heavily on the Finished messages; there is no earlier point in the protocol where the client-server session key is used. If Diffie-Hellman is used then this is also incorporated into the Finished messages.

The TLS specification is strict about verification of the verify_data contained in Finished messages, but leaves room for shorter verification data than cryptographically desirable. For this reason, the verify_data_length used for all GSSAPI CiperSuites is explicitly defined to be longer. The verify_data_length is listed for each CipherSuite, and is calucalted as the number of bits in the Kerberos cryptographic mechanism used, divided by eight and rounded up to a whole number of bytes.

Selectable values for verify_data_length were introduced in TLS 1.2; in earlier versions, the value was fixed to 12 bytes. As a result, support for GSSAPI authentication is not advised under TLS versions up to and including TLS 1.1, on grounds of the achievable level of security.

TLS Connection Expiration

GSSAPI Credentials have a limited lifetime. After a credential has expired, no application_data may pass through the connection, neither in plaintext nor in encrypted and/or compressed form. Both client and server will send the certificate_expired error report if the other party ignores credential timing.

Before this situation occurs, the client SHOULD securely renegotiate the session. This action MAY be deferred until it is required, for example to transmit a keypress. Similarly, the server SHOULD request renegotiation of the session when it has something to send while the service ticket is nearing expiration. The client SHOULD honour such requests for renegotiation.

Efficiency Considerations

The efficiency of the mechanism described here compares favourably with the common approach of authentication based on X.509 certificates.

The GSSAPI mechanisms for Kerberos5 are founded in symmetric cryptography, making them more efficient than the asymmetric algorithms that are used with X.509 certificates. Furthermore, the strategy for identity validations is much shorter-lived, which eradicates the need for chains of trust, CRLs, OCSP, DANE and perhaps more. The validity of a Kerberos5 ticket can be checked on the spot, and is considered so short-lived that expiration is a pragmatic remedy against most, if not all threats.

When DHE (or ECDHE) is added, a relatively expensive asymmetric operation is introduced, but the same introduction is advised for introduction of DHE (or ECDHE) alongside authentication based on X.509.

Security Considerations

To mutually prove authenticity, the client and server must use the GSSAPI Credential, which usually is a Kerberos5 Ticket, through the GSS_Wrap() operation. This operation is based on the session key that is provided to client and server in a form that only they can decrypt. The Finished messages verify that the parties can perform the same derivations, based on the same session key.

In Kerberos5, all key material is supplied by the KDC. This is a central point in each realm that is usually guarded well enough, but it is nonetheless a vital point in any infrastructure founded on Kerberos5. When client and server are in different realms, but have cross-signed directly or through a path of KDC’s, then all intermediate KDC’s are potential places where the session key could be located. The weakest KDC in the chain defines the lower bound to the security of the entire system.

Kerberos5 has introduced numerous refinements that are highly practical in daily use. One worth noting is S4U2Proxy, under which a service can request a ticket with which it can act under the authenticated name of a client. Such provisions are usually limited in the KDC through Constrained Delegation, but it nonetheless introduces an extra degree of freedom for attackers. Especially interesting is the combination with S4U2Self, which allows a service to obtain a client ticket without proving (in the Kerberos sense) that the client has actually authenticated, or even contacted the server.

Kerberos requires accurate clocks in order to operate securely; without it, once-used and since-forgotten credentials could be replayed by an attacker that has been able to recover an old service ticket’s session key.

Kerberos also hinges on the secrecy of the client password; if this is guessed, then all captured traffic can be decoded. This means that it is highly advisable to combine Kerberos with Diffie-Hellman for Perfect Forward Secrecy. In addition, given that tickets contain a rather large amount of information, it is advisable to apply encryption before sending the GSSAPI Credential; this can be achieved with a first handshake with Anonymous Diffie-Hellman, followed by secure renegotiation into a second handshake with GSSAPI. The use of secure renegotiation makes MITM attacks during the first handshake detectable. The choice for Anonymous Diffie-Hellman is more likely to be approved by servers when provided with the pfs_anon_setup extension, because that avoids application_data until the second handshake has been completed.

IANA Considerations

This specification defines a number of CipherSuites that use GSSAPI as its authentication mechanism. TODO: Incorporate verify_data_length based on the cipher key’s number of bytes.

This specification defines a TLS extension named “krb5realmnamelist”, which lists Kerberos5 realm names.