Most of the time was spent on two presentations. The first was the status of the GSS mechanism. We discussed issues that were discovered while implementing the EAP GSS-API mechanism. Discussion in the room tended to support the proposals made in the slides. A few issues will need to come to the list. We had the most interesting discussion of SAML AAA integration.

Minutes are available.

The new material was apropos for the venue. At the bar BOF back in March at IETF 77, we received several comments on Moonshot’s limitations. It doesn’t work well for services that require rapid authentications for multiple requests. There’s not a good story for use when a Moonshot service needs to contact another service. There isn’t a good standardized mechanism for mapping in domain-specific policy.

We presented a proposal that Luke and Sam developed to optionally provide a Kerberos ticket as part of moonshot authentication. This scales from a service that simply generates its own service tickets all the way through resource domains that have many services and complex policy and provide the client a TGT. Clients can implement the feature in order to achieve better performance. Server can implement the feature in order to get delegation support within a resource domain and to get policy mapping.

Luke has prototyped a version of this service involving a service ticket. We plan on briefly mentioning a desire to have extensible fast reauthentication support at the ABFAB meeting in IETF 79. However in the interest of getting the working group off to a good start we’re going to focus on the well understand parts of the system and formally propose this extension after IETF 79.

Meanwhile, at last month’s Moonshot meeting in Copenhagen, an initial version of the technology was demonstrated. We’re still working through some of the administrative details needed before we can release the code for public review. There have been several exciting discussions both on the Moonshot implementation list and on the ABFAB list over the past few weeks.

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

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.

You know what domain you are in. You look up using U-NAPTR to convert that domain and the label “lost” into a URI. You expect the URI to be an HTTPS URI and go to the LOST server at that address.

Finding the right server is important. An attacker could cause your 9-1-1 call to be intercepted by the attacker, or could misdirect critical calls. So, how do you know you have the right server? The current spec says you follow the rules in RFC 2818. You take the hostname from the URI and expect it to be in a certificate that you get from the server you talk to. That certificate is signed by someone you trust. So, you have a binding from the hostname to the public key of the server you’re talking to.

There’s one big problem. How do you know you got the right hostname? You just got this URI out of DNS. There’s dnssec, but you’re not actually using that today. Currently in the spec, you have no way to actually secure that the DNS information you got is the one you expect.

The problem is one of binding. For authentication to be secure, you need to establish a binding from some name that you trust to the party you’re talking to. That binding needs to be trusted. With LOST, the name that you have is your domain name. However, today, there is no way to trust the binding of that name to the result from DNS, so you don’t actually have a way to authenticate that you are talking to the right party.

Problems can get even worse in situations where you don’t have a name you trust. Let’s say you have some GUI that allows you to pick the service you want to talk to in a peer-to-peer environment. The services are described by user friendly strings. You pick “Bob’s computer” from the list. How can you trust that name? What stops anyone from going into their computer and renaming it “Bob’s computer?” For systems like the web, we can come close to solving the trustable name problem because entities can prove to companies like Verisign that they are permitted to use the domain name they are using. However in systems where people get to choose their own name and where there aren’t good ways to figure out if the person who chose the name is reasonably allowed to use that name, it becomes difficult or impossible.

All hope of security is not lost in this sort of situation, but there are attacks you cannot protect against. You can do things like make sure it is the same “Bob’s computer” that you’ve talked to in the past. Assuming of course that Bob never needs to reinstall or replace his computer.

At the TLS session, the topic of using EAP authentication in TLS was discussed. The IDEA is that EAP can be used within a TLS session for authentication either instead of or in addition to certificates. This would allow one-time passwords, SIM or other authentication methods to be used in TLS. In principle this could be very useful. There’s one significant problem: EAP has a fairly strict applicability statement which says that EAP should only be used for network access. There are a lot of reasons you might want this limitation. It’s useful to be able to distinguish EAP from GSS-API and SASL. When should one framework be used and when should another framework be used? Also, EAP is a three-party authentication protocol. The EAP peer authenticates to an EAP server typically by using a passthrough
authenticator
such as an 802.11 access point. However, EAP does not typically verify the identity of the passthrough authenticator. If EAP is only used for network access, this is a manageable risk; Russ Housley argued at the IETF 70 HOKEY session that for service provider uses of EAP, this may not even be a problem. However as the applicability expands, the identity of the party actually taking advantage of the authentication becomes more critical. You don’t want to give someone access to your mail when you thought you were accessing some wireless network. I think that this effort has enough support it is more desirable to figure out how to do it right than to try and stop it. So, the big question is what is necessary to expand the EAP applicability safely.

There was a BOF on web authentication. There seems to be general interest in doing the work although the problem is difficult. I hope to get Nico, Leif and the folks from Mozilla together.

The SASL working group is focusing on a new password mechanism designed to provide authentication and channel binding. We ran into two challenges. The first is that channel binding data may sometimes require confidentiality. Our existing approach for channel binding in SASL does not guarantee that the channel binding provides confidentiality. It also turns out that it is more complex than I had hoped to provide channel binding in a mechanism that is both a GSS-API mechanism and a SASL mechanism. For a GSS-API mechanism you want channel bindings to be included as part of the authentication exchange. However SASL does not take advantage of this but instead uses a wrap token. Ideally you would not need both facilities. I’ll discuss this issue on the list, but I’m not sure there is a good way around this.

HOKEY focused on the role of AAA proxies and EAP. RFC 3962 describes how we want key management for network access to work. Ideally keys would be shared by at most three parties. However real-world networks tend to involve AAA proxies between providers that also know the keys. There is a significant debate ongoing about to what extent we need to provide a solution to work around this problem. There is no ongoing work to meet this requirement. The good news is that the difference in consensus seems to be a lot less than I had originally expected.

I will speak to the Kerberos activities at IETF in a later entry.