• Managing groups of machines together
• Working with Active Directory
• Open source answers to the use cases of Active Directory if you aren’t a Windows shop
• Responses especially in the form of working code or ideas for getting there to my concerns about how we’re letting Microsoft drive the evolution in the enterprise
• Federated authentication, authorization and personalization
• Integrating with asset tracking, ERP, and other enterprise processes and how Debian fits in.
• Bringing enterprise players into the community as contributors to the project

Obviously, many other things could fit in and I’d be interested in your ideas as well.

Reading List

• Use case/briefing paper
• EAP GSS-API Mechanism draft
• RADIUS SAML attributes draft
• sstc-saml-binding-aaa-draft-00
• sstc-saml-eapgss-sso-draft-00
• Feasibility analysis of the approach
• Brief overview

Remote Participation

• Join our audio stream during the session
• Join our jabber chat room at moonshot@conference.jabber.postel.org

Kerberos 1.8 testing releases are already available in Debian Squeeze and Ubuntu Lucid. I will be updating Debian to the final release soon, but everything discussed here should already work in both Debian and Ubuntu. I don’t know about the state of other distributions, although given how heavily Redhat was involved in the process, I’m sure they have 1.8 internally.

One of the frustrating problems with previous versions of Kerberos was the need to key hosts before they could run Kerberized services. An administrator needed to set up a keytab and securely get it on the machine. That creates problems for automated installs of services, virtual services in the cloud, and environments where people installing servers are not the same as those running the Kerberos realm. Kerberos 1.8 still requires servers be keyed, but the need for the administrator is removed. Anonymous Kerberos provides a way for a machine to authenticate to Kerberos without an existing account. That page shows how the Kerberos administration server can be configured to permit machines to create their own keytabs. Anonymous Kerberos does require pkinit be configured and that the client know the public key of the KDC. However it is easy to build the KDC public key into an auto installer image or place it onto a USB key.

I think it would be really neat to build a Debian image for Amazon EC2 that would show how easy it is to boot a virtual machine, have it register itself with a Kerberos realm, use something like remctl to request a work load and then begin serving that work load. The work load could include both clients for distributed computation or even services provided to the world, all secured by Kerberos with automatic bootstrapping. I don’t know if I’ll have time to put this together, but if someone were interested in helping or paying for the work it would be much more likely to happen.

I believe the links above are enough that you should be able to get Anonymous Kerberos working and minimally configured. If not, feel free to send questions; I’ll focus more on updating the public instructions than on providing individual help, but I’m definitely interested in making this easy to use.

In the last entry, I mentioned that a preliminary spec would be available; see the preliminary EAP GSS-API mechanism. A use case paper and slide set are being reviewed internally and should be ready early next week. We may even have preliminary versions of the binding between RADIUS and SAML available before IETF.

There have been a number of great discussions on the moonshot-community list and with others interested in the broader area.

For web applications, there are a lot of options to achieve this: Information Card, Open ID, SAML, and OAuth all provide solutions in this space. However there are not good options for non-web applications. If you out-source your mail and chat infrastructure but want to use your own chat client or IMAP client, then you will not get the same federation benefits you can get with the web. If you’re using usernames and passwords and don’t mind the potential problems with your out-sourcing provider being able to impersonate all your users, you can simply synchronize usernames and passwords. Within an enterprise, you can do better using Kerberos. JaNet(UK) runs the UK Access Federation, which is a SAML-based web single-sign-on federation. In order to better meet the needs of their customers they’d like to expand this offering to non-web applications. This demand is apparently shared across the European academic community. I suspect there is also some demand in the US academic community and in enterprise situations.

With the web, it turns out that you have a convenient platform for interactions with the identity provider: you can simply direct a web browser to the identity provider and need not specify the user interaction with the web browser at all. This is seen as a significant branding and usability advantage. With other environments, it becomes necessary to specify the interaction with the identity provider. Consider an automated client that wishes to examine a mail box and provide advanced mail sorting or aggregation. That automated client cannot directly use a web browser. OAuth solves this issue with an enrollment step that does typically involve a web browser that produces a consumer key and an authentication step that does not. However for non-web clients it seems like avoiding reliance on the browser authentication will be important. It turns out we already have widely used technologies that do this: the Extensible Authentication Protocol (EAP) mediates the interaction between a subject and identity provider for obtaining network access. It also turns out that we have fairly good technologies for abstract security services within non-web applications: thanks to Kerberos and Active Director, many application protocols and a fair number of applications support GSS-API. JaNet(UK) proposes to combine these technologies with SAML in order to produce a solution for federation beyond the web.

I prepared a feasibility analysis of this proposal. At a technical level, the proposal is sound. There’s a lot of standardization and implementation work, but there appears to be sufficient motivation to form the seeds of a standards activity and put together a proof-of-concept implementation. However, the big question is “Will anyone use it?” In particular, to be useful beyond fairly small communities, support from client vendors and application framework vendors will be needed. It’s taken massive money and around 20 years to get Kerberos support to a point where it is effective within an enterprise. Moonshot can leverage that work to a large extent, but moonshot may also have greater usability and penetration goals.

It’s interesting that I’m advocating EAP for application layer authentication. When I was a Security AD, I made a strong statement that EAP must only be used for network access. I’ve been fairly consistent about that since then. I think there are two huge problems with using EAP for application authentication. The first is that EAP only authenticates the home realm; it does not authenticate what service you’re going to. So you might try to connect to your e-mail and end up giving something access to your stored files and pictures instead. That is, EAP has a phishing exposure in the federated context. If the only thing you can get by using EAP is network access, that exposure is only moderate. However in a fully federated environment that is a huge exposure. Moonshot will address this problem by using EAP channel binding and by doing the necessary work to make that a viable solution. The second concern is that interoperability is reduced when you have multiple authentication approaches for the same problem. If EAP is going to be used for application authentication, we need to understand how it relates to the rest of the application authentication metasystem. Moonshot proposes such a relationship, addressing my objection.

Moonshot is designed to work well with the objectives of the Identity Metasystem and its laws of identity. It uses a different technology, but does have an approach for dealing with claims-based identity and hopefully will have a user experience very similar to the identity metasystem. It uses a different underlying technology. However one of the main beliefs behind the identity metasystem is that is the user experience and universal interoperability that is important, not any specific technology. In its domain, the technologies Moonshot selects will be a better fit than a web services stack.

It’s strange not to be working on Kerberos; Moonshot uses some Kerberos technology, but its core is definitely not today’s Kerberos. In some ways it is fun to be working on something new. There’s one aspect of Kerberos I really miss: Moonshot has nothing like tickets. There’s no place to remember state or exchange to directly involve the client in what the server learns. My analysis talks about ways to make Moonshot more like Kerberos; there are some potential advantages, but so far, the tradeoffs do not justify changes.

We’re hoping to have a bar BOF at IETF 77 and a BOF in the summer at IETF 78.