Painless Security

Today, MIT announced the launch of the MIT Kerberos Consortium. The consortium will gather a group of interested sponsors around Kerberos and related technology. Kerberos has grown too large for one small team of MIT. In order for the pace of progress to increase, we need support from developers, users and support providers.

At the event, I discussed the technical direction for Kerberos. Within enterprise environment, Kerberos has achieved the goal of being painless. Many people use Kerberos on traditional computers without knowing they are doing so and without it getting in the way of them doing their work. Our challenge is to take this level of success and extend it to other devices, environments and solution provider communities.

Outside of the enterprise environment, Kerberos has had success in some specific product areas. Cable Labs has specified its use for VOIP applications in their networks. Microsoft has used Kerberos to back Xbox Live. However optimizing Kerberos for these non-enterprise environments has taken a lot of work. We need to learn from this effort and expand the protocol and implementation to make it easier. One environment where we have particular trouble is the web–both within an organization and especially over the open internet.

Kerberos works well on computers with traditional processing power, input devices and reasonably good network connectivity. We’ve had reports in the IETF that Kerberos requires a lot of processing power for sensor networks. Kerberos,especially in a cross-realm environment, is chatty as a network protocol. Try it some time over GPRS with moderate packet loss and a number of KDCs. At least MIT Kerberos does not perform very quickly in this environment. We need to think a lot about how user interface should work for mobile devices and other environments without standard desktop input/output. What do you want to do about passwords? How do you want to interact with the user to select identity?

Finally we have a lot of work to do in order to help developers of products understand Kerberos. There is not a lot written about using Kerberos in your product or protocol. The API documentation is in need of improvement. Best practices are not documented as well as they should be.

The consortium will work with its members to set priorities and allocate funding. Work will include improvements to MIT Kerberos, standards development and development of documentation. MIT Kerberos will remain an open-source project open to contribution both from consortium members and anyone else with time and skill. The consortium members will set priorities for how the consortium funds are used. Other contributors can of course choose what they want to work on in the context of the open-source project. The project will retain technical independence; consortium members can set priorities for funding but cannot force particular technical decisions.

One question we often get asked is how do Kerberos and SAML fit
together. At the IETF 69 in July, we got a group of interested people
together to discuss that question. Leif Johansson organized an
informal session to scope out the demand for interoperability between Kerberos and SAML. At that session, we identified three areas where work is needed:

1. Determining level of assurance for Kerberos authentication. SAML has a rich description of what forms of authentication and what context that authentication is in. There is a desire to reuse this facility for Kerberos.
2. Standardized description of authorizations. Proprietary platforms like Active Directory have platform-specific mechanisms for describing authorization. It is hoped that SAML may proved a solution for a standards-based platform-independent way to describe authorization.
3. If a n application uses the SAML Web SSO profile, it is difficult to get from that profile to Kerberos tickets for use in backend applications. There is a desire to work on a standardized solution to this problem.

A summary of the meeting is here
A mailing list has been organized to develop these use cases and if there is sufficient interest attempt to form an IETF working group to produce standards in this space.