In the TLS Working Group within the IETF there is a proposal called Flexible Key Agreement for Transport Layer Security (FKA-TLS), the basic idea of this proposal is that it should be possible to use a GSS-API mechanism to negotiate the key to use with the Pre-Shared Key (PSK) Ciphersuites for TLS; this has a number of benefits, for one when using GSS-API with Kerberos it’s no longer necessary to put your KDC in a location where its directly reachable by the client being authenticated.

Before I continue on the rant I feel the need to pontificate a bit, those that know me consider me a “PKI guy”; simply put I love the stuff it’s a great way to enable new scenarios; having a common bootstrapping infrastructure also helps accelerate development and deployment of new secure services. This is proven in-part by the ubiquity TLS has had in the market place, although there are non-PKI (the I is important here) as well as non-certificate based ways to use TLS they are not used in any significant volume.

Despite the success of TLS, PKI still has a core problem namely, all its value is for the relying party (e.g. user) but al the cost is for the subscriber (e.g. web server administrator); this isn’t a unique problem related to PKI, many security solutions have this same trait; what this does do however is limit the scenarios of where PKI based solutions get deployed, namely there needs to be a model (ecommerce, regulatory conformance, etc) to justify the cost for the subscriber to do the deployment.

The problem with this is that in many cases it’s not possible to identify a model sufficient to assume the associated costs; for example does it make sense to encrypt all the traffic sent to and-fro enterprise web servers? Probably, but does it make good business sense? Unfortunately the answer to that is usually no, one of the reasons for that is the incremental cost to do so is significant, especially if you don’t already have a PKI.

So what is the key message I want you to take away from this sub-rant? Just remember that PKI is the tail, not the dog; people deploy PKI to enable some other scenario they do not deploy it for its own sake (any more at least, a decade ago there was many who did this as a “strategic” investment but this is few and far between now).

The interesting thing is that PKI does has an alternative in managed environments, one that has slowly been penetrating both small and large enterprises it’s called Kerberos; most universities use Kerberos extensively, as do many “Unix shops” then of course there is Microsoft and Active Directory which also uses Kerberos; bottom-line is while PKI was busy focusing on the Internet, Kerberos won the Enterprise.

But what exactly was won? Well although Kerberos is a “Key Distribution Protocol” it really just won the authentication war; in other words its seldom used as a “key distribution protocol”; who is the winner there? PKI, and that’s directly attributable to TLS and the ubiquity it achieved on the Internet protecting ecommerce.

This brings me back to FKA-TLS, specifically what this proposal promises to do is give us the best of both worlds (PKI and Kerberos); with minimal changes to TLS we will now be able to leverage those KDCs that have been deployed in enterprises as a means to bootstrap TLS communications securely.

Although GSS-API by its very name is a generic API set, the most prolific GSS mechanism is certainly Kerberos, in-fact the two are almost synonymous; with that in mind there have been a number of “improvements” to Kerberos recently that when combined with FKA-TLS promise to deliver some very cool scenarios, some of those improvements include: 

• Anonymity Support for Kerberos – Defines extensions that allow a server to authenticate to a client without the client revealing its own identity (think Server authenticated TLS). 

• A Generalized Framework for Kerberos Pre-Authentication – Extends Kerberos to provide means to protect the Kerberos exchange from offline dictionary attacks, and lays the foundation for increasing this protection even further in the future through the application of a ZKPP based algorithm.

• Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API – Provides a mechanism in which a client can acquire the initial Kerberos Ticket Granting Ticket (TGT) for Kerberos via GSS-API (think Kerberos without your KDC directly on the internet).

With these improvements one can now do the unthinkable, leverage your already deployed infrastructure (Kerberos) to do interesting things! Some of the things that become possible include:

• You can enable TLS for all web services and web services that only need to interact with devices you manage (e.g. in the windows world any domain joined device) without having to buy certificates, deploy a PKI and deal with the lifecycle management problems of certificates.
• With minimal work in a EAP-TLS implementation you can now also do “secure PKIless” user and machine authentication, all using standards based protocols resulting in a interoperable solution.
• You can now use Kerberos without having to put your KDC in a location where its directly reachable by the client, for example you could use Kerberized TLS over the internet without having to put your KDC in a DMZ (which is a bad idea by the way).

These are just a few examples, there are lots of cool things you can do with this, well cool if you geek out on this sort of stuff at least.

The PKI guys will say people should just take the hit and use PKI, it’s not really that hard (which I kind of agree with by the way) and rationalize that point until their faces turn blue but the fact that you need to have that conversation is the point; in-the end the problem comes back to PKI being the tail, not the dog. More over there are other issues surrounding the use of the PKI in solutions, some of these are:

1. The use of certificates introduces fragility into the service offering (due to PKI implementation limitations not issues with PKI itself); issues related to fragility include revocation checking and certificate lifecycle management

2. The use of certificates introduces complexity, that’s not to say PKI is complex it’s really more that that if you operate a web server you don’t necessarily have the experience with it.

Another thing I have heard folks argue is that a Kerberos based keying approach is less secure than a PKI based one; the core rational behind this argument is that passwords “suck" (see: The Great Debates: Pass Phrases vs. Passwords. Part 1 of 3, The Great Debates: Pass Phrases vs. Passwords. Part 2 of 3, The Great Debates: Pass Phrases vs. Passwords. Part 3 of 3 and Microsoft Security Guru: Jot down your passwords), and they do but there are a couple things folks should understand to put that point in context:

• In Windows all machines have a “machine secret” a “password” that is generated with a strong pseudo random number generator, that secret (in VISTA as an example) is 240 bytes in length; it’s this machine secret that is used for all “machine” authentication scenarios. As for that secret’s strength IANAC (I Am Not A Cryptographer) take a look at this RSA paper called “A Cost-Based Security Analysis of Symmetric and Asymmetric Key Lengths” what you will see is that they say a 128 bit symmetric key offers the same effective strength as a 1620bit RSA key (note that 240 bytes is 1920 bits!) when used properly (VISTA also defaults to AES256).
• It’s also useful to understand that these “machine secrets” automatically get changed every 30 days (default), therefore the lifecycle management problem typically associated with certificates virtually goes away.
• Passwords are what people actually use, certificates are not portable without the deployment of specialized solutions like smartcards therefore they are not used in scenarios where portability is a requirement (most); thus although it would be fair to say a mutually authenticated TLS session based on 1024bit RSA keys is more secure than a typical password it’s irrelevant since the users in questions don’t have that as an option (in these situations my dad always says “what does that have to do with the price of tea in china?")
• Focusing too much on the fact that most passwords "suck" ignores the more fundamental issue at hand - It doesn’t matter how good your password is if you use it insecurely; it’s very common for universities for example to use EAP-TTLS with PAP, as a means to get the clear text password from the users PC to a server so that they can do a kinit (Kerberos authentication) with the supplied user ID and password to determine if access should be granted, this is insecure and they only do this because they don’t have a better option if they want to integrate with their existing infrastructure (there are other examples like this too, EAP-MD5, LEAP, HTTP Basic Authentication, Traditional Forms Based Authentication, etc).

As security practitioners we cannot simply put our heads in the ground and make arbitrary stands on principal, we must take a serious look at the needs and abilities of our customers and prescribe solutions that will improve their situation in a meaningful way; I firmly believe FKA-TLS falls into that camp, it provides a measured security improvement over what is being practically deployed and leverages the investments customers have already made to make its deployment secure, cost-effective and brain dead simple.