 So for the last presentation of the enterprise track, Sam Hartman is going to be talking about Moonshot, a federated authentication system. Sam has been a Debian developer for quite some time, maintains the Kerberos packages, and several other packages in Debian has also had a lot of experience with authentication systems working, among other things, with the Kerberos group at MIT. Thanks to us. So I wanted to finish today on, we've talked a lot about what the current state of Debian is and what people are doing, but I think it's always important to look towards the future as well. And so I'm working on a project that is, I think, a new enterprise authentication technology. We have a bunch of people standing up here talking about Windows and how important Windows is, and that's always true, but we need to remember that it's important for us to keep track, to keep control of our own destiny. If we are not innovating, if we are simply playing catch up with Microsoft or anyone else, then we are not moving the industry forward. Maybe we're making things cheaper. Maybe we're making things more free. But if we don't use that freedom to actually advance, then we haven't really accomplished a lot. So it's important for us to understand how Debian can be a tool to bring new things into the enterprise, things that aren't there today. And since I happen to be involved in a project that I think has that potential, I'd like to talk a little bit about that. And Debian's role in that project and how Debian can be a tool for smaller changes as well as the sort of big changes we heard about this morning. So the problem we're trying to solve, there are a lot of great technologies out there or at least a lot of technologies out there for dealing with authentication for web applications. We've got OAuth, OpenID, SAML. Well, that's great except enterprises are faced with plenty of thick client applications that just aren't the web. So is this use cases? Or is this? Oh, what is Federer? Okay, so in this talk, we're gonna be talking a lot about federated authentication. And for us to do that, I'd like to go into a little bit of detail about what I mean by federation. There are a couple of different definitions of federation. This is the one I'm gonna use. I think it's a perfectly fine definition. There are other definitions, though, that you might run into in other contexts. Federated authentication is when you have an organization or an organization that offers identities. This can be as simple as me running a server in my home that is my identity server. Or it can be as complicated as someone like Stanford University or even some huge corporation having thousands or millions of identities. And they have someone else out there on the internet who wants to use these identities to provide a service. It might be my bank wants to provide me a service and is willing to trust me to assert that I'm who I say I am. That'll take a while, but we could hope. Or it might be something like I'm an enterprise and I've contracted with someone to provide a service to my users. So let's look at what some of those use cases might be like. This is use cases, right? Okay, so the first use cases, we have exactly the sort of outsourcing that Evan was warning us against this morning. But in the enterprise, frankly, we all understand that this is often a reality. And sometimes someone can do something better as a service than we can. And so we'd like to be able for our users to use it. So imagine a university wants to outsource its email. And they want to maintain control of some of their data. And in particular, the critical data that identifies their users, they don't wanna give the outsourcing provider a copy of their password file. Instead, they would like the outsourcing provider to come to them and say, well, you know, this person wants to log in and here's who he claims to be. Are they legit? Yes, no. And if so, what's their name and what's the other information we need in order to use them? The second use case is things like great computing. The one of the project leader on this effort, Janet UK, has identified a number of organizations in the UK that are in the high performance computing space that want to offer high performance computing as a service, you know, and also that want high performance computing for business continuity. The final use case is something that's really important to remember is ever present in the enterprise. That's, I've got some random application. You've never heard of it before, but it's really important to me. And it's some application within my enterprise or some application between my enterprise and a couple of small business partners. It's not important what this application is, but it's really important that it work. I'm sure anyone who's spent any time in the enterprise can name, you know, many of these. And it's really important that your technology work well with that. So this is components? Oh, actors, okay. So there are several of different people who are going to be part of this. I want to go through and describe a little bit what we're trying to accomplish and the technologies we're using. Then I can sort of go and discuss what software is involved and how Debian fits into the picture. So one of the actors is the identity provider. And in the enterprise context, we generally think of this as an organization, you know, basically the enterprise. Note that in the public web context, there are plenty of people who want to even sell you this. You know, Facebook would love to be your identity provider. Amazon, with Amazon pay phrase, would like to do that too. So would Google, so would, you know, lots of people. But in the enterprise, this is typically one of the things you're actually going to want to own yourself. And so, you know, Stanford's probably gonna be Stanford's identity provider, et cetera. Another organization is the service provider, someone who's providing service to your users. And then there's the glue in the middle, the federation. Some thing or someone who's providing trust between people who don't always know each other. Now, in some cases, this can be peer to peer. Basically, I can directly have signed a contract with you that says we're gonna trust each other and, you know, you're gonna accept my identities. And so the federation may be kind of a NOAA. But there are a lot of cases, you know, things like in common, edugain, that sort of thing in the education sector, a lot of federations among business sectors where the federation is a very critical part of this. Basically, it's a legal entity that is designed to reduce the number of contracts you have to sign, as well as a technical entity that is designed to reduce the number of, you know, complicated agreements you have to, complicated protocol conversions you have to do and to actually get a level of interoperability. And I think that's it for this, so, what? Okay, so, going on to what all we're gonna have to do, build in order to make this work, this is the components, right? So, we're gonna need to specify some way that you talk to your identity provider and that you authenticate with them. This is different than the web federation systems. The web federation systems pop up a web browser and basically argue that the exchange between you and your identity provider is out of scope for federation. There's a problem with that, it's called phishing. Actually, there are a couple of problems with that. One of them is called phishing and another one is called the where are you from problem. You can get into some dreadful situations where the system is prompting you to say, which of these 900 organizations is sponsoring you? Pick from the list. And that's really not a great user experience. Phishing may be a great user experience, but it's still undesirable. It starts with a great user experience. Yes, and so, we would like to avoid it. And basically, in designing Moonshot, we've decided that the way to avoid it is to actually think about the interaction between you and your identity provider. Pretty clearly, we need to have an interaction between the service provider and the identity provider. That's the actual federation. So the service provider, effectively, there's a disconnect. Basically, the protocol you speak to the identity provider can be completely separate from the protocol that you speak to the federation. That way, you can use whatever smart cards and that sort of thing you want. The second, but then, we're also going to want to think about how the identity provider describes you to the federation. Basically, how it makes statements like what your name is, what your entitlements are, what access you should have, what organization you're a part of, that sort of thing. Okay, so then we're going to go into a little bit of detail about each of these. This is the authentication signs? Okay. We've chosen to use the Extensible Authentication Protocol for you talking to your identity provider. You may have used the Extensible Authentication Protocol. It's what 802.1x uses. Basically, it's very popular for logging into wireless networks. One of the reasons for this is we have a lot, there's a lot of experience with that, with eduroam, and with a bunch of wireless things that are beyond, that are enterprise beyond the education sector. And one of the great things about EAP is that it supports pretty much any credential, from my standpoint, ironic exception of Kerberos, that you might possibly want to use. Whether it's username and password, certificates, weird biometric stuff, one-time passwords, whatever. EAP can do it. For Federation, we're choosing the biggest Federation protocol in the world. There are a lot of people who go talk about how many web identities they have, how many open IDs there are. There are a lot more cell phones. And frankly, the cell phone and wireless industry has a lot of experience with triple A, with something called triple A protocols, radius, diameter, that sort of thing. And the education sector, where Moonshot is originally coming from, has a lot of experience with radius. And so basically, radius is the most successful Federation protocol that we have today. And so we've chosen to use it. This is app integration? We've chosen, so we need a way to get into the applications we care about. Your email reader, your web browser, it's a little bit ironic that we're talking about needing to get into your web browser for authentication for non-web, but it turns out that there are some cases where you need that. Your instant messaging client, your, you know, whatever, take your pick. The Kerberos community has done a lot of trailblazing for us here, with GSS API, both at the protocol level. Everything from SSH to IMAP to XMPP to DNS even, supports GSS API. And there's pretty good support, especially in Debian for this in Kerberos. The support for things other than Kerberos is not as good. But it's there, and we're gonna make it better. How am I doing on time? Great, we're doing great. So, since we're doing great, we're going to frighten you with a picture. This is network access. And basically what we have is multiple entities. On the left, and I hope this diagram came out when I cut and pasted it from another deck. My side view is not up to actually producing the phone on my own. Although I guess I could have used Graphis. But on the left, we have the client, which is divided into, basically, there's an EAP supplicant, and then there's an EAP lower layer, something like 802.11. And on the right, there's the network access, you know, your access point. And your authentication goes off to the AAA server. And so basically what this means, you know, that's on the further right, right? Even, right, okay. So, and then on the far right is the AAA server. And so basically what happens here is that you have a tunneled conversation, you basically are talking to the authenticator, the network access point. And the network access point is taking all your traffic. And in that traffic is this EAP packet, which the network access point really can't, once the conversation really gets going, understand it's encrypted. So it's tunneling and it's allowing you to have a private conversation with your identity provider, the AAA server over on the right. And at the end, it and you both learn a key, as well as some authorization attributes about you. And so basically this, that you see all the components we were talking about. You have a protocol between you and the IDP, EAP. You have a protocol between the IDP and the service provider, AAA. You have security against phishing, you know, all the things we want, except this is network access and we might kinda wanna do a little bit more than network access. So, we change the labels. We haven't really changed the protocol flow much. I mean basically this is more or less exactly the same thing. Except rather than using a network, we have an application like an email reader in the middle, or in the, you know, between the left and the middle there. We still get a key, we still get, you know, the ability to do protection against phishing, all the sorts of nice things you'd wanna do. This is the point where terms like channel binding and EAP channel binding and GSS channel binding and protection against men in the middle all come up and I'm happy to go and discuss any of those details. But basically there are some subtleties here. But the high level thing is that we've managed to turn network access into application access. There's some work to do, but basically what I'm trying to show with these two slides is that conceptually it's the same thing. Okay, what is this? This is, so that's an overview of our technology. Now I wanna talk about the project. We believe in open standards, we believe that the easiest way for people to be able to understand and analyze things from a security standpoint is to go right down what it is. And so we're gonna do that. But we also believe that for technology to be successful you have to actually have code. And we need open source code because that will, well first of all because that will drive adoption and innovation and you know, I don't really need to sell why open source code is good to this community. But we're gonna do that. And we're also going to try and actually put it together in a test bed and deploy it and see if it works. And we'd love for people here to be part of that. So, roll with it, no. Okay, so basically right now there's a website, www.projectmoonshot.org. There's actually a project plan using what as far as I can tell is the best project management software Debian, Task Juggler. It's scary if you've never used it before. You write up your project plan as a program and compile it into project reports. It's absolutely great for me. I was shocked when the client was excited about using it. But it's actually been a really wonderful tool. We have a bunch of open mailing lists and we have a bunch of documents that are gonna turn into specifications. We have implementation coming from across a number of different organizations. Some of them are being funded by Janet UK. Some of them are being funded out of the Gen 3 project. Some of them are coming from other places. Really pretty exciting group of people. And of course, pretty soon now we're gonna have some repositories and code. But we also need to get this integrated into an operating system for it to be useful. Which brings us to the role of Debian. Debian, that's this, okay. So the goal here for Debian, basically you have this problem if you're trying to really sell a technology in the broader world that sure, you've got this proof of concept. And if I get enough tin cans together and whistle in the right way, maybe I can hear the voice from the next room. And maybe I can imagine how in a hundred years that might actually turn into a world spanning communications revolution. But the guy I'm trying to convince that this is great may not have my imagination. So it's a lot better if I can actually just build the world spanning communications revolution. Of course, that requires actually getting it into the hands of everyone. Well, it doesn't just work that way if you go up to some commercial company and say, hi, I think I've got a good idea. Don't you want to go put it into your product? They say, well, where's our customer command? Wow. Your customers won't demand it until they understand how good it is and until the people they want to talk to have it. But with Debian, you can go up to the project and you can say, hi, I want to help. I want this new, this cool new idea I have to be available. People will say, well, you know, is it actually going to, is it going to break things, is it going to get in the way? But these are technical discussions and your proposal can be based on the merits of its actual technology and on how much effort you're willing to put in to the project. You know, if I went to Microsoft and said, hi, I'd love to, you know, I don't want to come work for you, but I'd love to sit there and help write a bunch of code for you to use in Windows. They're not going to go for that. Even if I would do it for free. But you know, if I come to a Debian developer and say, hi, I'd like to help you out, you know, making your package better and adding new features to it and work with you to get these into your upstream. They're not guaranteed to say yes, but they generally do because we are a community. And that's the value of Debian, is it basically allows you to take a good idea like this and to have a chance to put it together as a real part of a production operating system so that it's actually in the hands of end users all over the world. And it's a tool that's available for anyone building off of Debian. And to be able to be part of the community and to do that focused on your idea rather than on what business relationships you can sign. And I don't think anyone else can do that. It's an amazing power that we as a project have. Okay, roll or, okay, so here, so let's get down to some details. What are we actually talking about in terms of the kind of work that needs to be done with in Debian? This is one of the things about this project is it's a very, it's, it is a very large, well, it's both a vertical and a horizontal project, but basically there's a lot of small changes needed everywhere, which is something that many project managers, I talked to Blanche and Horror at. But frankly, Debian's really good at that. I mean, I can go open 50 bugs, all with small patches, and if they're on different packages, there's a pretty good chance that, I mean, I'm gonna have to go triage them and see which ones get taken and which ones don't. But we actually know how to apply manpower to that kind of patch review across a bunch of different packages very well. So what do we need to do? We need to, you know how I mentioned that the applications were good at Corrosion GSS, but not really so good at some other things in GSS? We need to fix that. That's gonna be small three or four line patches to a bunch of packages. I like a few cases a little bit more. Another thing we need to do is we need to actually package the GSS API mechanism we're using. Well, I mean, that's a new package. It happens, I'm maintaining one of the GSS Google libraries. I think I can probably manage that. You know, if not, I'm sure I can get some help and that won't be too hard. We need to package some extensions to free radius. Though we're working on getting them incorporated upstream. We'll see how well that goes. I need to work with Fedon to get, he maintains the radius client we wanna use and it's gonna turn into a library and we're gonna work with him to package that. Then there's the second part of the project having to do with SAML integration. This is actually a little bit scary if to those who understand what's involved, at least the bottom bullet here. But basically what we need to do is get some extensions into some of the SAML infrastructure in Debian and also get some extensions to an ISE weasel extension and some extensions to Apache. All of these are things that really ought to be fairly easy to deal with. But that's the sort of thing that it takes to actually put this together as a real tool in an operating system. What was this? So how are we gonna do that? Well, that's pretty obvious. I mean basically we're gonna go put together a bunch of disks and work with upstreams and work with packages to integrate the disks and offer to help out. I mean basically one of the things we'll do is where we can split the technology we need off into its own package, we'll do that and I'll maintain it or one of the other people involved in the project will maintain it. Okay, what do we have here? Right, so there are a lot of ways that you can get involved in this work. First of all, we'd be very interested in people who want to help code, want to help add support to their favorite application, want to join our discussions. One thing I'll, want to join our design discussions, want to write code, want to test, want to help us package. One thing I'm gonna discuss in a little bit of detail here because I think people may assume it's hard and it isn't, is participate in the ITF. I actually should have said and, well, and OASIS there. A lot of the standardization effort we're going to be doing is in the Internet Insurance Task Force, the same people who bring you things like SMTP. ITF meetings are kind of expensive. That's okay. You don't need to go to ITF meetings to participate. To participate in the ITF, you need to join a mailing list. And you need to write, sometimes you need to write documents in XML and turn them into text files. That's really it. Basically, it's a consensus-based organization in many ways similar to Debian, except it tends to actually build consensus in a bit broader of a community. There's not the concept that if you own the package that you own the changes to the package. Within the Debian community, there have been some concerns about patents in the ITF. They have a more open to patents policy than we do. Well, we're, okay. They are, that is at least a perception. There is, however, there are, if any of the authors of Moonshot or of this technology had patents relevant to parts of the technology that were, that have already been discussed, they would have already needed to declare that. And no one has made such a declaration. So you can draw your own conclusion about whether the patents are a real issue in this space from that, basically. They would have had to already say that there were patents and no one has made such a statement. So there's our website at the bottom. If you're blogging about this sort of stuff, let us know, we can add you to our SS feed. If you wanna get involved, we have some mailing lists, two of them now. And there's a lot of implementation work. We'd really like to work on this. At this point, I'd like to open it up to questions. Anything about the broader, questions and discussion, anything about the broader issue of Debian and as a tool for this sort of change and an evolution of the enterprise, as well as the specific technology, whatever you want to ask, discuss. Let's have fun. So for those three part diagrams, what keeps the thing in the middle from replaying my credential? Where are we? Keep your roll of Debian, keep going. Yeah, that's fine. So this is the client server, EAP server. Right, okay. So it's a multi roundtrip exchange. There's an aunt. So math, gotcha. Math. I'm not sure if I understand correctly in this diagram. Does it mean that all my client applications you'll have to be linked against the GSS API, which is already the case, but also against a radius client? No, so your application wouldn't have to. The GSS, so your application is probably already linked against the GSS. The GSS is going to dynamically load a GSS, the moonshot GSS mechanism, which one of its shared library dependencies will be libratsegproxy, which doesn't exist yet, but will sometime this fall. So yes, but you don't need to make any change. You don't inherently need to make any changes to your application. Yeah, but this seems to me a somewhat complex architecture. In this way, for example, bugging in the radius library makes all your applications vulnerable and so on. And also I see that on your website, you talk also about NFS. How would that work for NFS? So lib, rpc.jssd and rpc.gsssvcd are the two things that would link against, the two things that would link against. Okay, so it's all in user space. Oh yeah, it's all in user space. We're going to export the same context that Kerberos already exports. As far as the vulnerability, actually one of the nice things about this architecture is that it limits the number of parties you're willing to exchange things with. Basically yes, your application will have a radius client. However, it will only open outbound connections to radius, only to a particular radius server that you have chosen. And you can do arbitrary filtering in that radius server for radius protocol stuff. So basically you have a proxy point, effectively you have a firewall point built into the architecture where you can do as much security fire as long as you want. But yeah, ultimately I showed you the slide with the parties involved in the Federation. Ultimately you have that many parties involved and so ultimately each of those parties can be an attack surface. Thanks. Jeff Crompton from Trinity College. I was just wondering if IETF still require a working implementation for a standard to be ratified? IETF is, okay, so there are, well first of all we hope to have one, so that shouldn't be a problem. Second of all, there are three levels on the internet standards track. The bottom level proposed standard which frankly is what a lot of things for example XMPP, SSH are at, does not require multiple implementations. The upper two levels do. There's a sort of feeling in the IETF community that our standards process is a little too broke. The fact that things like SSH, which I think people realize SSH is a reasonably mature technology, haven't bothered to advance along that track, suggests that perhaps advancing along that track is too hard. At the plenary and in last week's IETF meeting we basically discussed some simplifications. We're still going to set it up so that there's still belief that there's value in documenting when you do have a real implementation of something. And so there is going to be a level that reflects that, but I believe that one, Moonshot would be valuable even if it didn't reach that level and two it should be able to reach that level. Hi, I have a, I guess it's more of a. Name please. I'm Greg, I'm a local technologist. I am a participant in a team that is working on roughly the same project so this is more of a plug and a request that you come to our talk if you can make it. We're doing the same sort of thing, but instead of using like radius and GSS API we're kind of leveraging the same sort of ideas but using OpenPGP to build a web of trust and we have things for like a SSH using them as SSH keys and plugging them into the broken X509 area and authenticating websites and trusting websites based on that versus these other technologies. And this is a very interesting thing and it's outside of our kind of expertise. The radius idea is not one that I had ever considered just through my own lack of experience. Well it's a different, so the difference you have chosen a path or an optimization which is great if you can make it. Basically you have the same credential namely a PGP key throughout the system and in an environment where you can make that optimization there are some security advantages and there are some other complexity advantages. Others, complexity advantages. For example the US government has chosen to do that. The credential of choice they've chosen rather than PGP is X509 and certificates. I understand why you would want to do PGP instead for your model. I would actually recommend that you take a look at doing a GSS mech because it may make application integration easier for some applications that you care about. But it's a very interesting, yours is a very interesting idea. It doesn't meet some of the enterprise constraints but what I'm doing doesn't meet some of your constraints. So it's great to have multiple different approaches on different places on the spectrum. I mean our approach was certainly one from a different perspective and it's very interesting to see it from another side. Oh absolutely. But I think the GSS angle may actually help you guys out even in what you're doing. That is a very big concern is how do we get clients to start. Right and basically that's an area where we could collaborate because basically the work to get a client working with multiple GSS mechanisms is basically the same regardless and it's a work where especially in Debian we can really collaborate because we can do the work of making sure that all a user has to do is install either the Moonshot GSS mechanism or your GSS mechanism and the rest of the work is common between our projects and the way we collaborate. Yeah absolutely. And so I'd be delighted to work on that. Yeah yeah we would be very happy to work on that. I'm not a GSS guy but we have some folks. We can help you I mean with that. Yeah absolutely I'll be great. Hi my name is Buju Maya Dengtu from Stevenson's Institute of Technology. I'm a researcher. First I'd like to add a note if I may and I will ask you a question. Well I think there is a clear difference between authentication and certification to coming back to your point I think it's necessary to draw the line in between and the need for federated login systems rose from the fact that a lot of users actually use different services from different websites and most users actually seem to use the same username over the internet and users may also use weak passwords as well. So the federated login system is actually excuse me, providing a way to kind of facilitate a process for the user so that they don't have to enter the same credentials over and over again. And you know open ID is again another layer playing not the role in between. And the concern that I wanted to point out is the privacy issue and I don't think I heard you talk about that. Because federated login systems as useful as they are, just bring this problem with them is the problem is that the user may authenticate himself or herself to the server, the IDP and then IDP connects to the server and the IDP keeps the login information for the user with a full name and their email address and sends that information to the server and the server keeps record of their online activity, online behavior and their email address or the username or whatever. And this information can be traced back to the user so it creates some privacy concerns and privacy issues. And there has been a recent development in this area. There's a new concept offered and it's called pseudo ID and it was offered by Stefan Weiss from MIT. This is a very recent project that's still work in progress that I as the last time I checked it hasn't been published but the idea is using Chowm's eCache model to play a role in between this whole thing. And what it does or what it offers is that there's actually too much information running between the user and the server and the identity provider. In order to authenticate a user, you don't need to provide that much information and what happens is the identity provider instead of keeping all the full name, record and email address and everything. The identity provider sends the user a token and the user uses that token to authenticate themselves to the service provider. It's a little bit awkward and not really straightforward to get but I believe a project like your project being still underdeveloped on Debian can greatly benefit from that kind of privacy precaution or just the extended additional level of privacy. Thank you. So we actually, okay, there are a finite number of things and I really probably should have for this audience included the privacy spiel in here. That's not the solution we've adopted but I believe that the solution we have has practically similar security properties. So basically how much information is released by the IDP to the service provider is a matter of negotiation between the user, the IDP and the service provider. This is absolutely critical. Remember this is a European funded product and we have to deal with the European data and privacy directive and so basically we absolutely have to do this. You can release as little information as, here's a random identifier that is unique to this single authentication and that's all I'm gonna tell you. They're from my organization. I'm gonna tell you this random identifier or you can release claims about the user. They're over 18. They're one of my students. They're one of my employees. They have classification TS-Q or you can go all the way to, here's their full name. I've sent you a copy of a sequence copy of their genome. You know, here's the hypnotic suggestion that will allow you to take over their brain. You know all the way up to that depending on what level of privacy is appropriate between the service and that. The current version basically makes that a model of policy but it's something where we sort of understand that we can move it to a consent framework in the future and actually get the user more involved in that discussion with no change to the architecture. A little bit to that. I mean I think that the privacy issue is actually one of the really major places where open ID is not an adequate technology and the SAML technology stack is much better because the SAML folks have actually thought a lot about information control. So in a SAML universe, your identity provider usually knows a fair bit of value because that's where you're authenticating to but your information can stop there and because your identity provider has complete control over how much information that they release and there's also a strong tendency inside the SAML community which is already being used to authenticate people to things like Google and to things like salesforce.com and some of the other cloud applications. There's already a strong sense in the SAML community that you by default release nothing and you add specific attributes requested by a particular service provider only when that service provider absolutely needs it and that's all you ever release and that's already working with the web federations and so extending that model forward to other sorts of applications that makes a lot of sense and it means that you're dealing with that privacy stuff up front and people who are SAML consumers are generally used to getting things like unique identifier keys that where every single different application you authenticate to gets a completely different identity for you but each time you go to that same application they may get a consistent identity for that application if that's what that application requires. Right, I will admit I'm not the privacy person involved in this project but that's I, you know, that's okay cause there I can name two or three people who are. Any questions? We have another 15 minutes on the schedule. Well, we can get dinner early. Thank you all. Yes.