OK so the title of this post is a bit over the top but I wanted your attention, do I have it? Good!
Yesterday I did a post on the topic of FKA-TLS, for those who don’t want to bother reading that post for context FKA-TLS allows you to negotiate the keys for the TLS session using Kerberos (e.g. without PKI/certificates); it’s quite cool what you can do with this once it’s in place.
In this post I wanted to explore what value a enterprise that has adopted FKA-TLS would get out of a enterprise PKI; but for us to have that discussion we 1st have to look at what Enterprise PKIs are typically used for:
- Issuance of machine certificates for use in network authentication (IPSEC and 802.1x)
- Domain Joined
- Non-Domain Joined
- Issuance of machine certificates for use in server authentication (server authenticated TLS)
- Internal, e.g. for employees to “securely” access internal confidential resources like human resources and finance websites.
- External, e.g. for partners and/or customers to “securely” access resources exposed by the enterprise.
- Issuance of user certificates for use in user authentication.
- Internal, e.g. to employees most commonly on smartcards.
- External, e.g. to partners most commonly in software.
NOTE: I have excluded document/mail signing/encryption from the above usage scenarios since Information Rights Management (IRM) has seemed to have taken over this role in many enterprises since it more naturally support key recovery (regulatory need) and offers more granular control over content than straight document signing/encryption.
This list is not a inclusive list but it is representative of the typical usages of PKI, now if we ask our self how many of those scenarios could be addressed through the use of Kerberos (with the assumptions associated with TLS-FKA) we find that with the exception of the following:
- Authentication of non-domain joined machines.
- Authentication of non-employee users (partners and/or customers)
- Authentication of company assets to partners (e.g. public TLS)
Kerberos can be used as a direct replacement for PKI, it’s not that Kerberos could not be applied to those problems it’s just that the work to enable these scenarios with Kerberos has not yet been done.
The “PKI” approach does have some security benefits, for example you can purchase security hardware (HSMs, smartcards, etc.) that helps keeps the asymmetric keys “secure”; that’s not to say that in the future you can’t have the same sorts of protections with symmetric keys (in-fact TPMs have the potential to give you much of this protection in the future) its again that this work has not yet been done.
Now don’t get me wrong I am not saying Kerberos is the “right” answer, I am just saying its plausible that in the near future Kerberos will fit better into places where only PKI based solutions would fit today.
With that in mind what are the sorts of things PKI needs to do to continue to be relevant in the enterprise (this is actually what I wanted to write about in the first place), some things that come to mind include:
> Support for the enrollment and lifecycle management of certificates for manually enrolled certificates – Kerberos has this down, there are no services outages for Kerberized services due to credential expiration, to be fair this is a harder problem for PKI given its “baggage” but if PKI wants to continue to remain relevant this needs to improve significantly.
> Support for the enrollment and lifecycle management of certificates (both user and machine) on non-domain joined resources – Kerberos implementations today do not typically deal with this scenario, most presume a tight (normally singular) relationship with the KDC, PKI doesn’t have this problem but these solutions seldom offer life-cycle management unless the machine is fully managed; this has to change.
> Make is brain-dead simple for me to find and enroll to a public certification authority and still get lifecycle management – In the 90’s browsers like IE had a ISP sign-up wizard, certificate enrollment needs something similar; I should just be able to run a wizard that lets me choose where I want to get my certificate from, it should present me offers available from the various issuers relevant to my usage scenario and without leaving the wizard I should be able to get the certificate for my scenario and have its lifecycle managed so I don’t need to worry about it expiring and my service going down.
> Make it work locally, build in rich support for self and peer trust – One problem PKI has had is that it focused too much on the I (infrastructure) and not enough on application enablement; one very common way technologies proliferate is through grass roots efforts by people who are passionate about that technology, embrace these people help them lead their organizations by example through building rich support for peer and self trust based on X.509 certificates (see: Why self signed certificates are not a sit).
> Better integration with identity management infrastructure – Using Microsoft’s solutions as an example what I would want to see is every DC have a CA on it (see: A chicken in every pot and a CA on every DC), when I create a user that user should be added to a group that results in it getting a certificate via auto-enrollment, when that user gets suspended all certificates associated with that user should get suspended, when that user is deleted all certificates associated with that certificate should be revoked.
> Make it easier for relying party applications to “do the right thing™” – Right now relying party applications/protocols need to do far too much work if they are to support PKI properly, platforms like those provided by Windows should provide abstractions that make it easier for them to consume the technology; for example providing some common UI for specifying what constraints should be applied when validating a certificate chain and having a API that can take those serialized constraints and make sure the certificate in question meets them. Right now each and every application does this on their own and frankly they do a poor job of it, either implementing it wrong or omitting important knobs/dials making it hard to deploy the application.
> It’s time for a user interface make-over – User experiences for PKI have a couple key flaws, the first of which is that they presume people actually know what a certificate is next they build technology focused experiences vs. scenario focused ones and finally what user interface PKI components have are “dated”. The InfoCard “like” solutions seem to grock this, they have tried to build user interfaces around metaphors and use scenarios, these same concepts can easily be applied to X.509 experiences, this will be key if you want people to use the PKI plumbing.
> Ship technology in-box that takes direct dependency on it, make that technology first class – Sure Windows, Internet Explorer, Firefox, OpenBSD and other software out there ships with base support for the base technology that makes up PKI but if you don’t have something in box that leverages that in a main-line scenario it’s not likely to be used. Consider building in generic file encryption feature or a password manager that leverages PKI for portability and including it in the box.
This is a pretty big list, and it’s certainly not complete but I do think that it does a decent job outlining the high level work that needs to be done to help PKI get to the next level; I have hope that these sorts of things do happen, the biggest problem when it comes to foundational work like this is that from a product standpoint unless someone’s sitting there saying we want to buy something that looks like “n” it’s hard for organizations to fund this sort of stuff.
Only time will tell how things proceed, but I am very optimistic that we will see “good things” for PKI in the future.