TLS-KDH

This is the approach initially proposed on this site. It wants to use Kerberos + Diffie-Hellman as two angles on the cryptographic wish to provides encryption and authentication aspects that enhance each other.

The approach taken is to make ANON-DH more attractive as a preparing phase for Kerberos5, and then to commence into a Kerberos5 exchange wrapped into GSS-API packets. The GSS-API exchange also exchanges or acknowledges the Diffie-Hellman secret in the context.

There are various alternatives, some of which have been brought to me as the direct result of talking to people about this. I gratefully summarise these alternatives below.

Moonshot / ABFAB

As suggested by Janet.

The Moonshot application framework implements the work from the IETF workgroup ABFAB. The design comes down to:

• The purpose is to arrange cross-realm trust with an explicit "Trust Router" component
• A new GSS-API mechanism to encapsulate EAP
• Peers install software for this mechanism in their GSS-API stack
• Applications that equate GSS-API to Kerberos5 need a bugfix

Pros & Cons:

• Introduction of SAML into GSS-API, which is useful for cross-realm assertions
• Care of privacy by releasing minimal attributes and unlinkable identities
• Yet another protocol doing what Kerberos and OAuth also intend to do
• More suited for federation than internet-wide realm crossover due to the "Trust Router"
• A lot of software needs to be updated; Janet is highly active in this regard
• Documentation is not up to scratch (June 2014) but a topic of current focus
• No support for "Secure Impersonation" such as Kerberos' "Constrained Delegation"

Existing Kerberos support in TLS

As suggested by Simo Sorce at RedHat, in fact for deprecation by TLS-KDH.

In RFC 2712 a method is introduced to authenticate using Kerberos in a manner similar to what TLS-KRB5 is trying to do.

Pros & Cons:

• Ready to use, and usable for all TLS applications
• Client wraps a pre-master secret which only the proper server can decrypt
• No support for PFS; and keys from a prior ANON-DH phase would be replaced
• No negotiation for realms, which makes realm-crossover more difficult
• Only supports Kerberos, no other GSS-API (or SASL) protocols
• Support for 40-bit "US export quality" keys

The option of a prior ANON-DH deserves some further thought:

Prior ANON-DH would setup an encrypted layer; that would protect the Kerberos ticket

• The TLS-DH mechanism could make such ANON-DH acceptable
• The established Diffie-Hellman shared secret could be saved for later reuse
• A TLS Extension could indicate that the master pre-secret must be prefixed with the DH secret
• Realm negotiation could also be done in a TLS Extension, similar to the ServerName Indication
• Altogether, this is pretty complex and requires major code changes in sensitive parts of TLS implementations
• Remote realm name suggestions would need to be checked in DNS, ideally with NDSSEC, to avoid MITM attacks based on a rogue realm
• Isn't it better to rely on realmnames from DNS instead of negotiating them? Kerberos clients can figure out with their KDC if they are crossed-over to those realms

The solution of integrating the ANON-DH secret here is pretty much undoable; the specification is clear about how the master key is established, namely generated at the client and sent to the server in wrapped form; this drops any prior arranged PFS properties and reduces the secrecy to that of the Kerberos infrastructure.

Full GSS-API exchanges in TLS

As suggested by Josh Howlett of Janet.

In draft-williams-tls-app-sasl-opt a proposal is made to incorporate SASL into TLS.

Pros & Cons:

• Proposal has been rejected by the TLS Working Group of IETF
• More complicated exchanges than the usual three exchanges of TLS
• Less total roundtrips than running SASL inside of TLS (thanks to piggybacking)
• Very general; it can support SASL, GSS-API, Moonshot, Kerberos5
• Not necessarily a solution for integration of Kerberos and Diffie-Hellman
• No true integration between TLS and SASL; it is a mere optimisation because TLS and SASL are not cryptographically bonded

GSS-API as a protocol of its own

This is just an idea, I don't know if actual work is being done here.

It is possible, at least in theory, to treat the exchanges of GSS-API as a protocol on its own, and exchange it directly over a TCP connection, or better even, over SCTP.

Any architecture that currently attempts to run SASL and/or GSS-API over TLS may want to consider this alternative. It would be very interesting to have such an alternative to TLS, and protocol commands STARTGSS to mirror the now-common STARTSSL commands.

Needless to say that the conceptual protocol can be made to function within this framework without much effort; it easily runs withing GSS-API and thus also within SASL.

GSS-API authentication for SOCKS5

The protocol defined in RFC 1961 specifies how GSS-API can be used to authenticate against a SOCKS5 proxy. Many tools support such a proxy, but not all of those would support GSS-API as the authentication method. So, in reality, the chances of enhancing the reach of a protocol through this mechanism are minimal.

KDH as a GSS-API (wrapping) mechanism

The combination of Kerberos with Diffie-Hellman is the core cryptographic wish of this project; furthermore, to make that available in TLS. It may however make sense to incorporate it in a more general fashion, for instance as a GSS-API mechanism.

Such a mechanism would start off with a Diffie-Hellman exchange to establish a shared secret. Then the Kerberos5 mutual authentication would commence, encrypted with the DH shared secret, to exchange the session key provided by the KDC. However, this KDC session key would not be the one that would be used to protect further communication; instead, a combination (such as a hash) of the KDC session key and the DH shared secret is used. Any further use of this combined key would fail in the presence of active MITM attacks (whose only gain is identity information on communicating parties) and since the price of discovery is likely to be too high for the gain, the only option left is passive observation -- with only communicating IP addresses as gained information.

Less interactions would be possible if the Kerberos5 ticket is sent without encryption by the Diffie-Hellman secret; the session can then be setup if both ends send their halves of the Diffie-Hellman key exchange and if the client combines this with the ticket submission. The passive observer would be in a position to detect the ticket in transit, unless it is encrypted to the server's key. The remainder of the protocol would of course need to establish mutual authenticity, but if this is TLS then that follows from the Finished stage where each transmits a "signature" to the other side for the purpose of verification; in TLS 1.2 the length of this signature can be made to have a cryptographically decent size.

Such a setup would differ in the number of exchanges when compared to plain Kerberos5 exchanges, but would be available in a very, very general manner. Then, any mechanism supporting GSS-API (including SASL) would be able to benefit from the extensions.

This work would lean on the work done in the Moonshot project, which is already liberating many GSS-API implementations from the prejudice that Kerberos5 is all that matters for GSS-API authentication. It is especially encouraging that the one truly closed platform that remains, namely Windows, has no quarrels with the general idea of GSS-API; Microsoft has a long history of running a (rather weak) authentication protocol NTLM running next to Kerberos5.

It may be awkward to an end-user to have to choose between two Kerberos5 mechanisms for GSS-API, if they appear the same. The "only" difference would be that this version incorporates PFS, but that would just be brought to the end-user as "more secure" which will hardly impact their everyday joy in using Kerberos.

DH as a "keytype" in Kerberos' AP protocol

While setting up a session, Kerberos5 has the ability of submitting a so-called "subkey" as part of the authenticator in an AP exchange. The response can also include such a "subkey".

The field is defined as follows in RFC 1964:

subkey[6]   EncryptionKey OPTIONAL

This is further expanded in RFC 4120:

EncryptionKey   ::= SEQUENCE {
   keytype    [0] Int32 -- actually encryption type --,
   keyvalue   [1] OCTET STRING
}

keytype
   This field specifies the encryption type of the encryption key
   that follows in the keyvalue field.  Although its name is
   "keytype", it actually specifies an encryption type.  Previously,
   multiple cryptosystems that performed encryption differently but
   were capable of using keys with the same characteristics were
   permitted to share an assigned number to designate the type of
   key; this usage is now deprecated.

keyvalue
   This field contains the key itself, encoded as an octet string.

The intention of the subkey mechanism is to provide a replacement of the session key (for the AP session requested) to be used instead of the KDC-supplied session key. The exchange of the session key is encrypted with the KDC-supplied session key, so it may be straightforward to include Diffie-Hellman keys instead.

Looking at the encryption type registry installed with RFC 3961, there are indeed RSA- and DSA-based keys intended for use with pre-authentication with the KDC.

There are two ways of incorporating a DH-based algorithm here:

• As an explicit exchange, where AP_REQ and AP_REP each provide half of the key exchange, if they can support it. If the context also exchanged a DH key, it may be good to validate that these are the same, possibly by enforcing that they are the same, or by providing a secure hash of the key;
• As an inheritance from the environment, where a "contextual DH key" is imported as the subkey; this may include authentication of that key through a secure hash.

Pros & Cons:

• The RFC would be almost trivial; an extension of the enctypes registry with Diffie-Hellman key agreement for Kerberos5 seems very sensible;
• The integration into TLS would be pre-arranged by RFC 2712 which could be quickly incorporated into GnuTLS;
• It would require updates to Kerberos implementations; in particular, the Windows code base falls outside the control of private patching;
• Inasfar as it concerns TLS through TLS Pool, it might be possible to overrule local Kerberos problems;
• The implementation in plain Kerberos5 stacks does mean that no special GSS-API mechanism is needed (without awkward selection between seemingly equivalent mechanisms);
• The approach would continue to work if the Internet moved on to draft-williams-tls-app-sasl-opt or a direct GSS-API protocol;
• The implementation in plain Kerberos5 stacks also means that SASL is covered;
• The mechanism change can gradually migrate into mainstream use, as GSS-API stacks develop, provided that the sides can negotiate whether to use this option. KerberosFlags can be allocated to accommodate this process, and may be mentioned in the tickets of both clients and servers. KDCs unaware of the flag are supposed to ignore them.

Conclusions

There have been various proposals to integrate Kerberos into TLS, but not all have worked. Some have failed before they reached RFC status and others did not work out, perhaps due to their simple security model.

The most bold proposals are more general than support for Kerberos5 alone; they aim to incorporate GSS-API or SASL in general. Notwithstanding the tremendous advantages of doing this, it is a complex and long path to do that; specifically, these protocols require a dynamic number of exchanges, which is not supported by the TLS protocol. Changes to that end are considered rather intrusive for the protocol.

The conceptual protocol that we devised for TLS-KDH can be implemented within the framework of TLS, and this may be our best option to get this mechanism started quickly. On another front, we would then worry about realm crossover, specifically for Kerberos.

This would lead to a TLS-KDH that is not split into TLS-DH and TLS-KRB5 components, but a direct integration:

• During Client Hello, the client offers TLS-KDH cipher suites and possibly a set of realms it would be willing to support; it probably also sends a ServerNameIndication.
• During Server Hello, the server chooses the TLS-KDH cipher suite and may offer a set of realms (or perhaps just one) that it welcomes for the request announced in the Client Hello; in addition, it sends a Diffie-Hellman key exchange message in plain text.
• During Client Authentication, the client sends a Kerberos5 ticket suitable for the requests in the Server Hello; in addition, it sends a wrapped, fresh Diffie-Hellman key exchage.
• Both parties derive the Diffie-Hellman shared secret and use it to construct their master key as they normally would for TLS_DHE_KRB5_ and TLS_ECDHE_KRB5_ cipher suites; they then construct and submit mutual proof of holding the master key.

The Diffie-Hellman key exchange could be run in plaintext, but wrapping one side of it introduces mutual authentication; the client can only encrypt if it holds the Kerberos session key; the server can only decrypt if it holds the same key and thus is the KDC-registered principal.

TLS ends with a validation of the mutually matching master key; note that it has taken until 1.2 to introduce an option that permitted cryptographically safe lengths for this validation. But also note that the actual exchange would be garbled just as well, and getting through a slighly insecure validation does not add much value to an attacker.

Discussion

Please sign up to our mailing list to discuss any issues raised by this page. The list is highly specific to the topic of KDH and its integration into TLS.