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.

I wrote about the challenge of securing high-performance connections in NFS. One of the technologies that will be important to making that working is channel binding. You perform some application layer authentication and then bind it to a high performance cryptographic channel at a lower layer. The framework document describing how channel binding works has been published.

The document describes channel binding as a concept and gives requirements for how to use lower level cryptographic channels such as IPsec. The document doesn’t define specific details of any given channel but does outline what would need to be done. Work is on going in the BTNS working group of the IETF to specify this for IPsec.

The document goes on to discuss how applications can use these channels. The SASL working group has defined a binding for GSS-API binding that supports channel binding. That has been a good validation of the design.
We will also work on using this in NFS, which should continue to validate the approach.
I’m very excited at the progress we’ve made with this concept.

IPsec seems like a good fit for RDMA security. Packets can be decrypted before they are passed to the TCP layer. There is one huge problem. The sort of infrastructure you need to authenticate IPsec is not what you typically use to authenticate NFS. IPsec authentication tends to be per-host not per-user. IPsec doesn’t have a good way to work well with Kerberos. (There are a couple of mechanisms but they have non-ideal components.) One solution would be to have separate authentication at the NFS layer and the IPsec layer. That is very problematic because it increases the cost. Also, the authentications can become mismatched and that decreases security. A huge cost is that two security infrastructures are harder to use than one.

The solution is channel binding. You generate a cryptographic name for the IPsec association. Then, you exchange an integrity protected version of this name over the GSS-API channel. Both ends of the channel confirm that the cryptographic name actually corresponds to the IPsec association. One nice thing about this is that the IPsec-level authentication doesn’t matter. It is important that both ends are the same, but it is not important to tie them to any real-world subjects. The down side of this approach is that it does require more complex interactions between the two layers. The advantage is that it actually provides security that is relatively easy to use.

Channel binding was designed for the NFS usage situation. However as Nico discusses, it can also be applied to other situations such as the web.

Unfortunately the NFS specs being presented for approval side step the problem of security that performs well completely. I think that’s going to be a long discussion.

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.