15516 >>: It's really a great pleasure to introduce Carl Gunter to you. He's well known in a variety of work he did in the security area. He worked for government, with government. Had good press on some of his projects. He started a company. I know him for many years, and he used to be at the University of Pennsylvania, but a few years ago he moved to the University of Illinois, and that's I guess one of his new projects. Welcome. >> Carl Gunter: Since this is a generalization of some work that I'm doing jointly with this collection here of colleagues at the University of Illinois, the purpose of the talk here is that I wanted to discuss attribute-based systems for security and, in particular, to look at their illustration in a particular system that we've been developing. The goal in part is try to delineate some of the difference between what this refers to and what you might call classic security systems. And the advantages of these systems are, you know, in areas of management and formalization and for new middleware and applications and I hope this illustrates some of the kind of idea there. The illustration in here is based on attribute the-based messaging which I'll now explain. So an attribute-based message system sends e-mails to parties in terms of basically a database query is the e-mail address. It's useful for enterprise systems where you might have access to an enterprise database that contains information about principles that could be used as the basis for these addresses. So it's a little bit like a listserv, except the recipients are dynamically determined by the address and so it's as if you create a listserv dynamically on the fly from the enterprise database. So in this case you're going to have something like an e-mail message to all the female graduate students in engineering who have passed their qualifying exams be could sent out and it would go to that targeted group. So the advantages of things like this are, first of all, I don't know about you, but I get a lot of irritating enterprise messaging that is basically spam but my spam filter refuses -- where it's hard to filter out. And part of the reason for that is that people send messages to broad mailing lists even though they may be only for fairly limited groups of people. And so an efficiency thing here would be that you could try to target things more precisely for the people who actually need the message. Like if you needed to send a message to all the faculty on sabbatical, a typical way to do that now would be to send it to all the faculty. But it would be nice if you could avoid six-sevenths of the wasted messages you would send that way, both in terms -- mainly in terms of the waste of time of the recipient who sees yet another message that they don't really care about. Another thing is the exclusivity, which a lot of the messages would go to mailing lists that you'd like to be a little more refined. Instead of sending it to a big group send it to a smaller group. Maybe it's something that's a little bit sensitive. You do this thing all the time. People create listserv things just for specific groups, because of the sensitivity of the messages. Here this can be done on the fly. So, for example, all the tenured faculty serving on conflict of interest committees. Of course, all of this is assuming that I do actually have a database that can access where that information is available. So I'll continue to assume that through most of the talk here. Intentionality is another feature which is it's often easier to describe recipients of a message than to actually list the recipients. So this is the old logical distinction between intentionality and extensionality. So, for example, I might or might not know who the attending and ordering physicians are for Smith, but maybe I don't really care. I just care that these are the people that need the message and I don't care who they are. So I don't want to know their e-mail addresses. Now, to do this, there are some design challenges that come up. One of them is access control. So this gives you a great power to hit targeted groups. And so you ask on what attribute should be able to send a message. So can you send a message to all the faculty who make more than $150,000 a year who if anyone should be allowed to do that? Maybe you could figure out who that list is but not just anybody should be able to send such a list undoubtedly. You could have like a super admin who is the only person who can send such messages, but then that kind of wastes a lot of the power here, which would be really something where you would allow a broader group to use the facility under a suitable access control system. Another one is encryption, which is ideally you'd like to encrypt end-to-end so that the mail relay, if it's compromised, doesn't compromise your sensitive messages. It's a major technical problem. If the senders don't know who are the specific recipients, and I gave examples there where you don't know, don't care or shouldn't know, then how do you encrypt end-to-end for them. So that's a question that some of the new cryptography techniques can answer. And a third point and one I'm not going to go into in detail except to indicate a little bit about some of the questions that come up here, which is you know should you know to whom you actually sent the message? So you know their attributes but do you know who they are. And should you know why you got a message, like what attribute got me on this mailing list? And then you can see up here things like if you got a message like this and didn't know where it came from and you answer it, then if you were supposed to keep it sensitive, who is on the mailing list on and that information will be compromised. So there's some tricky questions about the information flows that would occur here. Okay. So another thing about this is we had an idea on this project that we wanted it to be practical. They're actually interested in something you could use as opposed to conjecturing a whole new type of MTA or client that you would have to use. And so the obvious thing is to implement this in web mail where you can put all this stuff on a server to do this. But it's interesting to think about how you could use existing MUAs and MTAs so nobody has to use a special service to do this. Or at least the special service they use could be limited in some way, like just a web page to help them form the address. And then there are questions about the efficiency of the access control of the encryption. I'll get to this question here about how you do the cryptography, key generation is a concern. Then another point is, if it's too complicated to either form the address or describe the policies, nobody's going to use it. So it really can't -- or you're going to use it in a way that causes harm and then people are going to stop using it. Now, the approach that we have for this is to look at a combination of these two technologies here. I'm calling ABAC, or attribute-based access control. This has been around for a while, and I won't claim that it's something completely new, although I'll kind of focus on some of the differences it has with other things. And in particular one of our technologies here we were interested in is something called policy specialization, which is you don't want someone to send a message and find out they're not allowed to send it by its being rejected. You want somehow to tell people what they're able to do in advance so they can never form messages they're not allowed to send. And so when they approach the system you want to specialize a policy for them. It's a little bit like database view. So an individual approaches the database, you give them a view and they can query against that view. You want something similar to that in this context. The other one here is attribute-based encryption, which is a relatively new technology, only a few years old for encrypting in a collusion resistant away under attributes. So I'll explain a little bit more about that as I go along here. Now, this is the part where I was going to try to get a little bit of a distinction between these techniques and other techniques. This could be a bit controversial. I'll ask you to indulge me for just a little while before we argue about whether this is reasonable or not. But a kind of characteristic way of talking about security is in terms of access lists or capabilities. And so here you might, for example, have a table and you'd give a list to the people who have access to the table. So groups can be used for this to form the ACLs better. And yet in some cases you would prefer to describe the policy more intentionally. That is it's not in terms of a list of people who have access, but maybe in terms of an attribute of the people who should have access. And then the attributes might be something that you could derive from the enterprise database. So if you wanted to give access to a table to the managers, you could have a group of managers maybe manually maintained or you could have some link between the manager attribute in the enterprise system and the access control. So if you do that kind of linkage, it introduces various problems but also various advantages. And a contrasting thing here is role-based access control. And one thing I'm often asked about this is what's the difference between attributes and roles? And I think it's a tough question to answer because there are things that seem like they're definitely roles, things that seem like they're definitely attributes and then a lot of gray stuff in the middle. So, for example, being the chair of Chian Ching's (phonetic) thesis committee seems like a role to me, whereas being more than 21 years old seems like an attribute to me. I'm not playing the role of being more than 21 years old. And then there are things in the middle where they seem a little bit of each, like being a professor. So I like to think of the roles as a bundle of privileges often associated with a task, and we need to perform the task you activate the role within the session in which you perform the task. And it gives a variety of advantages in the management of permissions. But and you have techniques like role hierarchies and definitions to help you control the rules for what the privileges are associated with the role and who can occupy a role. But places often maintain -- argue that they don't want to have to set up any special kind of role system. And so this is a thing that I run into with organizations saying we're told we have to use role-based access control but I don't like having to set up the roles. Now, so let me try to argue in favor of this, the attribute-based access control here. Suppose you have Alice she needs to get access to a table in a database. So a way you can do this with fine grained access control is you put a policy that refers to the database and it may be the case that it's quite common to take the ACL, of course, and the ACL is in the database. In this sense it's reflective. So the database contains information that's about its own access control. However, you often, in these systems, see this as sort of stratified so that the ACL is kind of distinguished from the rest of the data. And so the ACL could not, for example, be modified by modifications of other parts of the database. And so that process would require some additional steps to make that happen. Whereas what you often want is a lot of information from the database to be used in the decision. So, for example, you would have -- whoops. You would have data about Alice that's being stored somewhere and then there would be data about the data being stored somewhere. This might be that Alice is a doctor and this might be that Sally's data about her patient record or EHR. And then you might have the relationship between the two data which says that this is the doctor of this. And so you would like to do the access control based on a combination of these things. It's not radical concept of course. What you would do is write an application that manages this access control with its own program logic and it uses this information from the database to make access control decisions. So the particular thing here that I wanted to kind of emphasize is that we would like to go towards more formal models of this kind of thing and of middleware that can do this rather than mixing it up in application logic. So the ideal thing would be to have say a language for doing this sort of stuff so that the security can be separated out into that language and you can reason about it. Now, the process of putting the ACL in the database with fine grained access control is so not sustainable that there are quite a few supplements to database systems to provide them some kind of system to do more like this sort of thing. So, for example, the Oracle VPD virtual private databases do something like this. But then I don't think that it's very easy to take the Oracle VPD system and reason about it formally and to understand it precisely. And so one hopes that we can move a little closer towards a more complete understanding of these kinds of access systems. Now, looking at the kind of core technologies here, ABAC, there's a lot of established ideas on how to use attributes and access control. The idea is not radically new, of course. One that was popular was X509 attribute certificates where you could have an identity certificate. And then in order to avoid having to put lots of information on it, you separately have a certificate that binds attributes to the identity on the X509 identity certificate. Then you see, for example, in dynamic tokens like [shibilith] tokens carry attribute information so you can use that for authorization decisions in addition to the identity information. And as I was mentioning before, there's a lot of implicit use in application servers where you go into the database here to get information about the principle. You go into the information there to get information about the data that's being accessed and so on. There are some new approaches. One thing I was kind of intrigued by I saw recently a trade press article looking at health information exchanges and urging the use of attribute-based access control matrixes, in effect kind of to draw access control matrices where the rows and columns are distribution of attributes. You say doctors have access to lab results. It's kind of a generalization of access control matrix based on attributes. Those are limited, though. I would think you could not in such a language express things like each doctor should have access to their patients. So you need something more sophisticated. Another thing here is in trust negotiation work, this sort of popular topic of how you swap credentials to find out about each other gradually. They've had a fair amount of work on this use of attributes to do those things. And one that we've been exploring is to look at transaction data log as a foundation for the reflective database access control, like I was showing on the previous slide. Now attribute based encryption is ->>: What's transaction ->> Carl Gunter: It's data log in which there's an operation to change the ground truths in data logs. They're execution changes the underlying true facts. The rules change as part of the -- it allows you to do things like suppose you wanted to represent this thing about if someone ceases to be a manager do they lose a privilege, then you run the thing and the database can change its actual truths. So basically gives you a way of modeling both change and rules that depend on ground truths. Okay. So now this -- we'll be focusing here on something called cyfer (phonetic) text policy attribute-based encryption, which is a new set of techniques for doing encryption on attributes. I wanted to describe the capability of this to you for those who haven't seen it before. First of all, you represent attributes as strings. So you can use any string as an attribute. It's possible to represent types like [boolean] and enumerated and numerical ranges. And numerical ranges are represented by, like, saying having three attributes that are boolean for like the first bit, the second bit and third bit. They're costly to do the numerical attributes, but many things need numerical attributes. Then you have an attribute authority who issues individual private keys to users based on their attributes. So I would get the professor key, for example. And then you encrypt using something called an access structure which is a tree with thresholds. So, for example, if you have two children and the threshold is one, it's a disjunction. If it's two, then it's a conjunction. And you then decrypt -- you encrypt this using public parameters and then you use the private keys in order to decrypt if you happen to have a satisfying collection of the private keys. And the hard part about this is the protection against collusion. So if I send a message to tenured professors in computer science, then an assistant professor in computer science can't collude with a tenured professor in ECE to get the thing decrypted. In particular, the way the private key is -- the faculty key that I have will be different from the faculty key that another member of the faculty has. Because we have an individualized attribute key. I won't go into the details how the cryptography is done for this talk. Now, let me turn back to the ABM system and talk about that a little bit. So there are three key policies that you get in the ABM system. So addresses in our case, I'll talk about our design here, but you could have done this different ways, are disjunctive normal forms. And you have literals that assert equalities or inequalities. You can write things like the position is faculty and the salary is more than 150,000, for example, would be an address. Then this is what we call a receiving policy. It says who you want to receive the message. Then another step as we talked about that it's not possible to let everybody send all these kinds of messages is what you would call the sending policy. And what you do here is you use ABAC rules to define the attributes a party can use in an address. And here it's kind of a tricky design. We did something fairly simple in order to keep the thing more deployable or easier to write. So you can imagine a complex access control system so that any combination you might make to create an address would be its own individual access control. Instead what we do we simply have a condition that says whether a particular attribute can be sent to a particular value in a message that you send. And then you're allowed to combine those in any way you wish. So, for example, if I can route on faculty and I can route on gender, then I can always, if I had been able to route on those individually, just send a message to both of the lists, with some possible redundancy, what's new here if you would be able to route on the intersection and send a message to the female faculty. So there's some question as to whether that would be an acceptable policy all the time or not. We didn't think of really compelling examples where we thought it was objectionable. Okay. So then you can that way control who gets to receive the messages using attribute-based access control based on conditions drawn from the enterprise system. >>: If I understand you correctly, the condition defines which attributes are available to you. >> Carl Gunter: That's right. So that condition right there might be faculty can send mail to faculty, that would be an example of a role. >>: So you have conjunctive conditions involved in the attributes, (inaudible) message for the properties for each attribute? >> Carl Gunter: If I had over here a conjunction like if, say, faculty and tenured like that, then it's what's on this side that is the encryption condition. See? So this is my permission over here and this is my address. But if I want to send to the female faculty, I can encrypt under both faculty and female. That's what the access structures give you with the thresholds. >>: If you have and/or combinations, then the other can be (inaudible) >> Carl Gunter: Yeah. In fact, one of the main things I wanted to show you for those interested in the cryptography aspects, I think this is one of the best new practical applications of attribute-based encryption systems. And we have performance numbers based on CPABE to show exactly what the limitations are for use in this application. I'll show you some of those. So, yeah, the more complex the policies are, the more it costs you to do this stuff. I'll show you how we estimated that. That was one -- I'm glad you asked because one of the main things we did in the project was looking at these performance scalability questions. I was afraid I was going to bore everybody by showing it to you. Maybe I'll just bore some of you. Let's go into reading policy here. So the attribute authority issues keys using the enterprise database like it looks up in the database whether I'm faculty. And then it says how long it thinks I can be faculty for and gives me an expiration key. So, for example, you can say faculty and 1998. I'm sorry, 2008. If you say faculty and 2008, then I'll have to have both sort of the 2008 attribute and the faculty attribute at the same time. So you can issue a group of keys and issue an expiry attribute and if people want to use expirations on things they can crudely expire things. And then you use disjunctive normal forms to define the reading policy. And this is the target encryption you're going to use on the messages. So this is going to provide you with your protection against a compromised MTA, for example. Now, the system looks like this. I wanted to give you a high level architecture and then do the three protocols. The high level architecture is that you have your usual MTA. In our case this was the University of Illinois's exchange server. In other words, no change to the MTA at all. You have a web server that supports ABM. You need a little bit of client software for the keys but not for the MUA. The MUA in our case was we used several, outlook and Firefox and so on. Then you need an attribute authority to issue the keys. That we had to code entirely ourselves. Well, we used a library from SRI for this. Then they have ABAC-end support system that does everything special in such a way as to try to avoid changing things much. In particular, on the back-end you have of course the enterprise database which you need to access for the attributes. And then our particular ingredient is a thing called the ABM server up here which is kind of the guts of the system. And it uses a policy description, a decision point which may be on the ABM server or it may be somewhere else. So this policy decision point is the thing that holds the policies for like who can send messages. The system is divided into three protocol groups that we call the policy specialization path, the messaging and address resolution path and the attribute keying path. And I'll just give you a sketch of how each one works. Particularly to show how the system avoids changing the existing enterprise system or client since that was one of the major deployment objectives. So in the policy specialization path, this is how you compose an ABM address and also get your permission to send the message. Okay? So the way you do this is the sender goes to the enterprise authentication server and gets a token. At the University of Illinois we have some special thing called Blue Stem that does this. It could be Curborose (phonetic) or something else. So Samel (phonetic) or whatever enterprise is used. Then you go to the ABM server with this authentication. And the ABM server then goes into the database here and derives using the policy decision point. Here it gets information about you, your attributes. Then it refers them to the policy decision point which comes back with your specialized policy, what you can do, represented as a web page, in our case, where you can kind of click things saying this and this and this, and within -- this or this and then within those this and this and this. So fairly simple to use. So it would be easy to cobble up the address for female faculty. That's not hard to write. For me to use that is easy. In its guts it becomes an X path. And so the e-mail addresses will be basically X path expressions. This one is the address resolution. This is how you send e-mail. So it's one little compromise in here to avoid changing the MTA and MUA. And it goes like this which is that thing where I got the X path, what I do is I save it into a file. We call it a .ABM file. I'm sure it's taken already. But the .ABM file is your address. And so what you do is you send your message to uiuc@, abm@uiuc.edu, a special address is allocated for the ABM messages. You have an ABM attachment that's then taken to be the address. So the address is then resolved by the server using the database. And so in the address list is the female faculty. Then you would go in here and find the female faculty. They would be returned as a list of addresses. So this is your dynamic listserv. Then this would be sent with Microsoft Exchange through an interface that's available for that that basically creates a dynamic listserv for just this message. And then that's sent out to all the recipients like this. The encryption is done at the sender, basically by encrypting a file. You take an attachment and encrypt it. We have a binary function. All this fairly clunky stuff, command line thing. But what you do you take your ABM address file that you just created together with the recipients that you want. I'm sorry, the ABM address together with your message body and then you run this function and it uses this package to encrypt it. Then that's sent out and on this end we have software to decrypt it. So I'll show you performance numbers on that stuff. Is there any question on this one. >>: Back to his question. If you can receive this, if your name is Bob or you're a female faculty member, your encryption will branch? You have to encrypt it both ways because Bob is not a female faculty member, doesn't have access to those keys. >> Carl Gunter: Yeah, that's right. Right. So that's the magic of ABE it does that stuff. I'm black boxing it mainly for this talk because I don't work on the cryptography stuff. But I appreciate it. So it does for this application something that nothing else could do. So you're right to hesitate on this and say how would you actually do that. And so that's what it will do. Note in particular, too, for like sending to listservs, you know often what you do is you trust the listserv to have all the keys of the recipients, which in a way throws out the baby with the bath water, because I mean part of the point of end to end encryption is you don't want the thing to remain on the listserv in clear text. So trusting the listserv to do all the encryption seems kind of pointless. And so here you encrypt end-to-end to a collection of recipients that you don't know who they are. >>: (Inaudible) encryption. >> Carl Gunter: Yeah. So you send out one copy, but the attributes allow you to decrypt it. So you don't have to do as -- in S MIME if you would do this, say there were 100 recipients, I don't know if there's specialization of this technique, but we would typically like have a hundred encrypted session keys included with the message and send it to all of them and they would find their session key. So in this case you don't have to do that. So when you come here to the attribute authority, the receiver comes to the attribute authority says I need my keys, okay so it goes to the database and it gives them their keys, back up here to the receiver and I'm skewing a few little security points here. The authentication to the AA -- I already talked about that. The enterprise authentication server does that. I'm assuming here that you also have an identity certificate for S MIME purposes, like an X5 or I9 cert. You use that to decrypt the message and get your copy. So I have my own special faculty key. I'm not sure if we thought that Bob was an attribute. But if we did I'd have my own special Bob key as well. So then the message from the MTA that you received is this decrypted using those attribute keys. Now, looking at this process, the obvious question was how big an enterprise could do this? And so what we wanted to do to try to calibrate it was to go for a middle-sized enterprise with ordinary machines. That's something the way a university of Illinois would be because your e-mail server is a fairly ordinary machine. Nothing special. Maybe not like a super computer or anything. So we were interested in like how much could you support with just kind of ordinary machines. So I don't describe the machines here, but the kind of stuff you might have on your desk. So we wanted to measure the costs on each path and estimate the latency for mid-sized enterprises and conjecture here what kinds of policies might you use. Now, this is one of the hardest parts. And I partly push -- I don't know if any of your are interested in this, but I do a lot of policy stuff and scalability. The question you always get is is this really scalable. The answer is it's hard to answer because nobody uses ABM now. So how do I know what kind of messages they're going to want to send? And so we had to come up with some idea how we could crudely test this given that we have nothing to go to and say, oh, here's our experience with lisservs and that's going to tell us how to do these dynamic ones or whatever. We used this Bethencourt (phonetic) and Highswater (phonetic) implementation of this cyfer text policy ABE library for this. They did a first version for us we used got some performance numbers, found some ideas on how to optimize. Told them. They did us a second version of it including more optimizations, but there were trade-offs between encryption efficiency and key generation efficiency that they exploited to improve in a direction that turned out to be the opposite of the direction we needed. And so their second version of the system was slower than their first version, which basically says that you have to kind of look at the applications to tell what you need to optimize on in this space, and we don't know this yet, I think. A big bottleneck here is key generation. Okay. So this is the policy specialization times. And so the way we did this was for lack of any more inspiring way, we would basically generate random policies. And so you would say something like I want to have five terms and I want each one of the sub terms, each one of the terms to have five literals or up to five randomly chosen. And so you would get like a cross section of this depending on what you chose it would generate a certain collection of random policies. The paper has details but what popped out of this was we got 143 rules in this random manner for one version. Then 282 rules in the next version and so on. So we got this rough graph which shows if you wrote 143 rules then it would take less than a second to decide what the user's policy is. Whereas if you're up here at 674 rules, it might take 12 seconds to do that. So somewhere in here there's some kind of like patience gap where you might say you gotta optimize this or people are going to be, you know, fed up with waiting. Or you might have to put in something we'll send you your address by e-mail or something like that. And so you do have a bottleneck here. It's not clear to me you're likely to have 674 policies -- 674 rules. So I thought this was kind of on the high end. 143 was not a bad estimate for what you might have. But then, again, who knows. So it depends on the organization and what kind of attributes we're talking about. >>: The shape. >> Carl Gunter: What? >>: Shape of the curve. >> Carl Gunter: Yeah. It's kind of that crudely linear. So now we did studies with the database. We did two databases. We did -- this was Microsoft's SQL server, SQL, and we also chose the Microsoft 2005 because you could also do XML with that. So we wanted something that would do both. So this is with Microsoft SQL Server. We did it in two versions, with the access control and without it, to try to at least look and see how much are you paying for doing the security stuff. And the security introduced an overhead here that you can see. This is sort of 95 percent confidence range. That's in milliseconds. And this is with an organization of 60,000. When we ran our random thing, the average list size, that is when you're sending one of these attribute-based messages the average list had 351 people on it. And so to do the resolution of the list, to find those 351 people took between 180 and 359 milliseconds, which seems quite reasonable to me. On the other hand, the X to know 1 wasn't so good. So there you see here this is in the several seconds range. So your through-puts are going to be hit pretty hard by this. I'm not sure you care much about latency here. Because this is like I send the message. If it's delayed by 7 seconds, you know, how urgent could it really have been, right? So on the other hand through put might be an issue. You might need a highly provisioned -- part of the reason we were thinking of this is that when you imagine the useful information in the organization that could be used for the messages, if you think broadly of everything as opposed to just what's in the HR database, it makes the thing enormously more useful. And you see lots of specialized applications now have bits of this kind of logic in them, like schedules have this, where you invite participants and so on. And so if you could really mine all that stuff and view it under one conceptual framework as an XML database, it would make the thing enormously more useful. So that's why we thought this thing would be interesting. We saw some presentations people gave on the idea of like using XML to characterize the entire information. I don't know if you work on this sort of thing or not. But look at the entire information infrastructure of the organization and give it an XML schema, and then you have like all of the underlying databases would be their different diverse technologies, but XML would allow you to unify those all in a single thing. Now, encryption is done on the client. And so I don't think it's very performance-concerning. We do have numbers. So this is -- if you have a lot of relation literals, then you're going to cost yourself for that. This is equality literal. So we can see here kind of the high end. If I have six equalities and six relations, more than 21 years old for this and is a faculty member for that, then it's going to cost you about 4.63 seconds on average to do the encryption, which maybe it would try some people's patience, but I don't think it's that bad. And the decryption times were about a third of a millisecond. So almost negligible. >>: If you have this running on like a source or something like that -- send message to if you want to send to the faculty that would be an equality that took half a second. 500ths of a second. >>: (Inaudible) the use of the same ->> Carl Gunter: That's right. That's very simple. So there's just one key in that case, right, as opposed to a complex of keys. So that seemed actually quite good. This is with a slower version of CPABE. Like I said, they changed it around. We were finding this was no problem. It was the other stuff we had bottlenecks. I'll show you that in a minute. So this is the generation of keys. And this was more significant. So here this is with numerical attributes and boolean attributes and we're doing it again from zero to six. But our system, our underlying system had 100 attributes. So we're talking about like this is assuming that suppose only six attributes are used in a given message, then I only need those six keys. So it's kind of reasonable to have a small number. So although there are 100 attributes maybe I don't need all 100 at once. If I did need 100 at once then you could project what these figures might look like. If you're going for like six of them you can see here a few seconds is required to get them. And so I'm going to the server asking for these six keys. It will take me a few seconds to get them. >>: Server generates the keys at a time ->> Carl Gunter: That's right. This is for on the fly. But you could have it generate them in advance, maybe. There's no problem having it generate them in advance. >>: So this is just the sender will log in and you would get dynamically with the keys and for the encryption process. >> Carl Gunter: No, this is the recipient. So I get a message, and it's been ABM encrypted or ABE encrypted for ABM. I say I need the keys for this. We didn't do anything fancy with this, and there's a little bit of a thing here which is you know remember I said earlier there's a question whether you know you're on a list. So one of the decisions we made was you know whether you're on a list because it has to tell you what keys you need. And so in particular the access structure under which this thing is encrypted has to be included in the message. In addition to the X path. So anyway the information about or rather derived from the X path. Anyway, you would be able to tell why you got the message. Or you could have gotten it in several different ways. Might be both you're in one group and another. But you would then be able to choose the collection of keys with which to decrypt it. So this is measuring how long it would take you to get them if you got them just at that point. So it gives the kind of general measure of how hard this ABM, the attribute -- this is one thing nobody has worked on that I know of is the performance concerns for an attribute authority if you would have one for attribute-based systems. That is attribute-based encryption. This is giving some clue. So what these are is different measures of the window of vulnerability that you might have for the system based on how long am I going to be able to keep a faculty key with an expiration even if I'm not a faculty member anymore. So I've done some heinous crime in the classroom and they've kicked me out immediately, I still have this faculty key. Now, I'll note that just because I have the key doesn't mean I get the message. And so there's a great deal of risk mitigation here, but if you're really paranoid about it, then you want short windows of vulnerability. Like maybe you'd like me out of the system today. So if you want me out today then we can support an organization of 10 users for this kind of thing, and so this is -- I'm skewing a lot of details here about like how big -- a lot of parameters are missing from this chart. But the point is that, you know, if I'm insisting on refreshing the keys every single day, then for most different combinations like this is 30 string attributes and 10 numerical attributes, if I have to rekey that many per day per individual across an enterprise. Like I said, this is a 60,000 person enterprise with 100 attributes per person, then I would be able to do 10 of them in a day. Sorry I'd be able to do 10 users. It's not 60,000 people, it's the -- I can support 10. I'm sorry is it in thousands? 10,000 users. Yeah, that was kind of important, wasn't it? Pardon me. (Chuckling) it's more scalable than I'm giving it credit for. So up here you can do quite well of course if it's just a month. That's not too bad, but I would say this one is representing a real bottleneck. If you wanted to rekey every minute or something like that, that would greatly impact the capability that you would have. So I do believe that rekeying on a monthly basis should be reasonable because you're talking about the rare instance where someone is revoked and they keep a key for messages that they're not supposed to get and you're worried about their breaking into the system and getting other people's messages for a month. So I don't know. I guess it depends on the organization. May depend on the attributes, too. >>: Seems like the reverse problem was, if I have an unexpiring message and you have to make a (inaudible) fix on the key server, you risk invalidating all of those messages. >> Carl Gunter: Oh, yeah, that's points one of the key aspects of the system what about keeping old keys. Right? I go away on my trip to climb Mount Everest, and I get back and my e-mail in bin is full of messages I can no longer encrypt. So what about how you're going to keep all the keys. You have really old messages and it's not issuing those kinds of keys anymore or whatever. A logical way in this application to do this it seems to me is to have a reasonable expiry on how long, how many keys you're going to keep. And to do something like when I read a message I reencrypt it under my identity key and put it back in the database. So that way you don't keep things in the attribute encryption in the system. So you just have a reencryption of that. So your old messages are always encrypted under your identity certificate. One could imagine lots of ways to cut that up depending on what kind of size you're trying to support for this. All right. Now, let me talk a little bit about the security and privacy analysis of the system. There is a question of how you enforce these policies for sending, receiving and reading. An important one, in the first version of this system, we had the idea that we were going to sign the ABM addresses and then you would send something with a signed ABM address. And then it would have like a time stamp on it. And this would help us avoid things like trying to rely on the security in the exchange server or whatever it is, making sure that the user who logged in is using their privileges to send the message out. And so we found after the performance numbers that you could really probably do this more easily just by letting the ABM message, the ABM messages be public and unsigned, that is, anybody could put them on the web page and do whatever they want with them. And then you issue them to people to help them make them. But then you also check them when they send the message. So basically they're checked both at the time they're issued and at the time they're sent. At the time they're issued you only check them to help the user make sure they're not composing something that won't get delivered. So these are always checked dynamically using S MIME. So what you do is you authenticate to the ABM server using S MIME and then the S MIME uses that name to do the check to see if you are allowed that send policy. Now, the vulnerability windows are actually rather interesting. One thing is when something expires, the receive might be a subset of the read. In other words, more people might be able to read it than could receive it. Makes no sense to have more people who can receive it than can read it. Kind of silly to do that. You just receive an encrypted message you would be frustrated to find you couldn't decrypt. But it makes sense in many cases to have the read policy exceed the receive policy. And in fact, this is one of the most interesting things I thought in this thing that I haven't really investigated much. And I'll just give you a little example. Suppose you're sending a message to Sally's attending physician. Then you might be able to encrypt under those attributes. But it might make more sense to just encrypt under the doctor attribute, since in most of these enterprise applications the doctors have access to everything anyway. And you just need to make sure that that is not available on an external server to a non-doctor in your organization. So having reading policies that are possibly way larger than receiving policies might be the most practical way to do this. It's just that you'll need a whole new raft of policy stuff to figure out what that should be. >>: Depending on how e-mail server is implemented, is there any way for sender to cache, suppose like change it. I can potentially compose an e-mail in my draft folder with the current policy, but send it later when I may not have otherwise access to that particular policy. >> Carl Gunter: Now, for the client, caching is no problem. So it helps me form a file which is like an address I can put in my address book. You can imagine extending the address books to include ABM addresses. So like the female faculty, if I need to regularly send to them, I could have that in my address book. The caching on the other end, like I want to kind of remember that this guy has permission to use that tool to avoid having to recheck it, we did that at first and then decided that we didn't need to. A principle that we tried to apply is whenever possible let the database do the optimizing. And so we were trying to assume that if something is frequently requested from the database, the database is smart enough to know how to make sure you can get that quickly. So if people are often routing on faculty, female faculty, then the database should be able to tell you the female faculty quickly. Maybe people who know more about database optimizations can tell me if we were unwise in that reliance. But that was a principle we tried to follow. >>: So for this particular example, if I compose an e-mail based on the current policy, and then put that e-mail in a draft folder ->> Carl Gunter: Yes. >>: -- 1 month later I can send that e-mail. >> Carl Gunter: Yes. >>: At that time I've got to recheck the sender to see if ->> Carl Gunter: Yes. If I sent it -- I don't have to go back to the ABM policy specialization system. But I have a risk that it will be rejected. So if it's been a year that it's been sitting in my draft folder, then it might be I no longer have the privilege to send that because of possibly policy changes at the organization as well as changes that might have occurred from my attributes. So in general I would guess what's going to happen is it's again one of these things I don't know what people are going to end up using something like this for. A likely kind of thing is sort of CRM-like messages where you need an administrator or someone in charge is broadcasting a message. Seems less likely to me that it's going to be for discussion groups, for example. But then what would happen is I'm a person who often needs to tell something to the female faculty. Then I would just keep that address and I would know whether I continue to have access to it. So if the MTA or the ABM server is compromised, you lose who sent what to whom but not the contents of the messages. That's what the ABE does for you. The clients, if you have a compromise client, you lose the information sent to that client and anything that they can get through a compromise that can use their keys. If you get two clients, you get the union of the two clients but no more than that because of the collusion resistance. So if I compromise a CS faculty member and I compromise a tenured assistant professor in CES and tenured professor in ECE, I still don't have enough to get the messages to the tenured faculties in CS. So those productions are made. And then concerning privacy, this is one where what we did was when we were forced to do something because it seemed like we needed to to make this work we did it. Otherwise we didn't try to do anything fancy. And our implementation, you don't get to know who the recipients are. But you get to know why you received a message. Now, here's a little bit of the related work. Attribute-based addressing for -actually, we found a patent on this. Patent application. I don't know if it was successful. So this crowd right here attempted to patent attribute-based messaging they called it attribute-based addressing. It's exactly what we're proposing here which is their application was CRM. And so they wanted, of course, if you're doing CRM things you wanted your address to be as targeted as possible so as not to dull your customers's interest in the messages you're sending. So they proposed an integrated system for using a -- now, what's very different about this is that although they're using ABM they didn't do anything with security. They don't even have a security concern in a sense because it's like someone who has his CRM list and he's going to be able to do what he wants with that. So what our work adds to this is the security dimensions, particularly. And intra enterprise use. Role-based messaging for medical applications is another thing that's quite close. I talked about the difference between roles and attributes. This is quite a gray area. So you might think of some roles as being determinable from attributes, and so when you have a way of getting a role from an attribute, then you can use our stuff to do role-based messaging. If you think of the roles as something outside the system that you can't get access to then you might not be able to do it. Then there's ABAC for trust management, I mentioned ABE for imposing access controls. Part of the logic for ABE is it can take your access control system and use encryption to impose it on somebody else. So like if I hand out some data to someone else, then the encryption enforces access control rules on that data. That's sort of what we're doing with the MTA in effect. Now, here's some more work we've done. We had a project called WS mail, which was one of the earliest parts of this. It was looking at what would happen if you redid e-mail in terms of web services. Particular study here was to look at using .NET to implement our new version of e-mail in which messages are not using SMTP, they're using SOAP. They're not using S MIME, they're using XMLD SIG and so on. So we built a WS mail system on .NET for this and studied performance numbers, reasoning about security. We also did this system adaptive policies which was e-mail where you can explain what your policy is to public and then they can react to it. So if you don't take attachments above a certain size, you can tell them so that they don't have to send a message and then call you on the phone and ask you if you got it. And then another one was shibilith RSS. We built a version of shibilith to do CDA health alerts where you go and you give them your attribute credentials and it determines the feed you get. So if you're like, if there's a health alert about a possible bird flu outbreak, you could have that feed go to just say certain kinds of doctors that would be the ones you would first inform of something before you scare the public with an announcement. My ABDAC is an effort to use existing database trigger mechanisms in particular in my SQL in order to implement using fine grained access control attribute-based access control. In other words, try to make attribute-based access control to be implemented with the existing database support mechanisms. Reflective database access control I mentioned already. You can Google us here. I wanted to say a little bit about the application spaces that we were interested in to give you an idea how we're trying to test the work. One of them is energy management systems. So this is an interest of mine that I'm not talking about today. Particularly security for the power grid. One of their big problems in that space is operator, vendor access to substations so they can check -- it's a little bit like I think my PC does this call home to Microsoft to check for updates and so on. It's hard to do something like that in the control system space because of their efforts to isolate the systems. So a big problem there is to figure out how you're going to update these systems in a reasonable way. So this would be allowing you to do things like Sweiser (phonetic) Engineering Lab engineer gets an attribute that allows him to get a role to go look at the configuration of a Sweiser Engineering Lab relay in a substation. So trying to develop a system to do that kind of thing. And then healthcare is an obvious application area where we might be able to apply this. Doctors really don't want to worry about things like who gets the message. So there's fairly -- I mean they definitely want it to be got to the right people but they would prefer themselves not to have to know the details. So we have fairly substantial systems in which you might say quote something in voice text and then someone transcribes it and figures out the rules for where that message is supposed to go and then how the thing is supposed to be checked. And so one thing you might hope for is more automation. So if I have some sort of rule that says that this has to go to the attending physician, the primary care physician and the ordering physician, then it would be nice if you could just say that as opposed to like trying to resolve who those are before it makes the message. On the other hand, a major trend in this space, as I went trying to sell this idea to people, a major trend in these HIEs is to try to get out of this messaging orientation. So what they want to do is to, many of you probably know more about this than I do, but they want to take all the data, put it in one place and give everybody access to it. So like a state might say all the people in the states are supposed to get their MRI readings from one place and then we put all that data in a database and then everybody gets access to that database. And this is how we get rid of this messaging stuff. And this runs into legal challenges with privacy. You're creating a big pool of people's data that can be accessed by lots of different people, unless you put an access control on it. And so there's some interesting questions about how you're going to describe that access control. That thing I quoted earlier about the access control matrices written with attributes was something I saw in the trade press about HIEs suggesting to people that might be a good way to write down their policies. So the e-mail messaging based on attributes is feasible and deployable in mid-sized organizations. We didn't try to find out what would happen if the organization were really big, but I think it could be done. We did in the case of shibilith RSS think about what happens with interdomain issues. But here a lot of that stuff of course is related to the possibility of having attributes that mean something to both me and to another organization. And so once you figured out how to do attribute mapping, then maybe the scalability things can just be sort of put on top of that. Like if you have two organizations of 60,000 and we've proved it's scalable to 120,000 then it will work. I think these policies, they're kind of simple, but I think they're intuitive. I mean I don't have any trouble giving many examples of these things and people give the examples back to me including some clever ones. I gave this lecture last Friday and it was at University of Texas at San Antonio. And someone asked if they could send an e-mail message to all of the faculty but one, the one that they're complaining about. [Laughter] so they want to know if the system could support negation. This is one we never thought about. But yeah, maybe you want one like that. So there are kind of a richer collection of policies from messaging that you might imagine here. And the examples can be quite intuitive. That's it. (Applause). >>: More questions? >>: As you work on your power system example, it seems like you're going to describe exceptions and denies become very relevant. >> Carl Gunter: Yeah, now, the way that -- so here's one of their big problems is they don't want to put like the permissions into the Edge devices, because then they have a big management problem with their permissions in the Edge devices. They want the permissions to be more like Curborose (phonetic) like or something more centralized. So we're trying to develop an approach in which you have a policy decision point outside of the substation and then the policy enforcement point is the relay so that is, that Sweiser's relay does the roles. And our decision point is based on attributes and it does the decision. So that's the architecture we're aiming for. So this stuff, this is fairly rudimentary, right now, what they have, with kind of heavy perimeter protections and then fairly vulnerable edge devices. And so our project, the more global project, which I'm not talking about today, is to look at ways of trying to make the thing more protected at the edge rather than so much dependent on perimeter and isolation protections. >>: I think I understood that all of your attributes right now are being pulled from a database. >> Carl Gunter: Yes. >>: Trying to determine the recipients of a message. >> Carl Gunter: Yes. >>: Have you done a study about a combination where say the majority of the attributes are from a database but some are dynamic? The example I have in mind is office server bank in Switzerland or many offshore banking can look at the customer records within the borders of Switzerland but nowhere else in the world would you look at the characteristics to determine the recipients or introduce some dynamic attributes that could introduce deny situations? >> Carl Gunter: I think so. The sending policies perhaps do that. You might have an attribute of like location. >>: The location is something that's dynamic. It's not just obviously if you have location and they were static. >> Carl Gunter: Yes. >>: Today I can but tomorrow I can't because I crossed the border. >> Carl Gunter: You have window of vulnerability challenges with the keys, but with respect to the attribute checks, it's not that hard. So provided the system knows. It has to have some way of knowing. So assuming it knows where I am, I think that that could be programmed in, yeah. I think we can do that with what we have now. >>: Some other examples in that same space are the health of the machine that someone is accessing, do they have virus software, do they have all kinds of things that can be an attribute security and something in the organization. >> Carl Gunter: It's interesting -- what we did we got from the University of Illinois a description of its HR database contents. And then we kind of made up some other stuff, and we did some statistical things saying here's what we think are the likely -- some attributes everybody has. Some are very sparse and we did some estimates from that. But we didn't focus on this question of like very dynamic attributes, like location of the sender. So I mean the Switzerland ones I know about that they're very fussy about where you are when you do your transactions banking-wise, for various international legal reasons and such or actually Swiss legal reasons, I believe, right? But we didn't have a long list of such things. There were other ones, what I'm thinking of the application areas, military folks kind of resonated with this, because you might send things based on things like security levels. So you could send messages based on recipients that had levels that relate to yours in interesting ways. So, yes, I really didn't look into any detail in that but it seems interesting. >>: So with respect to the attributes which can be used for dosing by the sender, is it something like just survivor (phonetic) groups or is it more like you can send it to people who have say (inaudible), is it a aspect of that. >> Carl Gunter: It could be. Could be. Yeah, so if you got a set of rules that said you had complete permission, then the way the thing would look is that you would have a list of all the attributes in the system and you could select. And within each one of those you could go in and that's the disjunction. And then within each one of those you could select a conjunction. >>: With the server (inaudible) the address. >> Carl Gunter: That's what I'm talking about. This is the addressing capability. So if you had like rules that signed lots of attributes to people they would have a big web page with 100 things they could work with at two levels. >>: You talked about using BP. Did you look at any other features for other databases. >> Carl Gunter: Yes. >>: DB2 or anything like that? >> Carl Gunter: Yes, we have a paper on that and it has a list of the ones that we checked. So we started with Oracle VPD, and what we were interested in was the idea of I create policies in the database and you create policies in the database and then how those interact. And you get some very interesting problems with respect to I run a query at either my privilege or your privilege, but you get to say my privilege but you get to rewrite it in the VPD. And then what happens is that it can leak information of mine because you're now running at my privilege. We sent this to Oracle and they, at first, thought it might be a bug. But then they wrote back and said: Well we just have one database administrator and everybody trusts him. So this isn't relevant. So there's a -- I understand why they do it like that, but as a scalability question of wouldn't it be better if you could have policies that are more distributed. And the other point was that we weren't doing it right. So we hadn't programmed it correctly. So there was a different way of doing it we didn't know about, which made us appreciate. It is tricky. And so that's why we wanted to look at this formal languages stuff. >>: You said you looked at other things. >> Carl Gunter: Yes. Microsoft's one has the same issues that we found and one or two others. So that we checked -- this is Lars Olson the student working on this he's the database person I told him to look at the major vendors to find out as much as possible whether the same problem would arise in the other products. >>: You have links on your website -- >> Carl Gunter: No, that's a paper we just submitted to CCS. But I'm willing to share it with you if you like. If Lars doesn't mind. I think he would be happy to share it. >>: Do all attributes have parameters. >> Carl Gunter: No, we didn't consider that. In fact, one thing we did was we first did a simple version with X path. So the idea was just to do no more than X path. Then they came out with the encryption stuff and we found that -- we told them you can do exactly X path. So your encryption can take these X path things and encrypt with them. I don't know, there might be some generalizations. They're all the time working on generalizations, like at CSS. There was one on revocation. So this thing has a very simple model of revocation and then we work with these vulnerability windows. But there is no revocation in this case. >>: Absorb roles in the attribute. >> Carl Gunter: I see. >>: Chairman of the committee for the attribute, chairman of the committee. (Inaudible). >> Carl Gunter: Yeah. >>: How about works four equals (inaudible) everybody who works for Bob except for Frank. (Inaudible). >> Carl Gunter: Right. Those are appealing example of that, everybody but one. (Chuckling). >>: Your key server has to go, would your key server generate a whole new key? >> Carl Gunter: Yeah, this is one of the things I thought was kind of crazy about the system. If you look at some of these more complex ones, it's clear you don't need all those keys. Right? So that's why I mention that thing about doctors, which was many cases it just seems like it makes a lot more sense to have the reading policy be a big envelope around the receiving policy. And so that would be a kind of next generation of work on this is to figure out how you describe the relationship between reading and receiving policies. >>: In terms of the performance, I'm just curious, if you had to try to maintain the (inaudible) table more on APN policies and (inaudible) are required to raise that e-mails to send to that (inaudible) policy. >> Carl Gunter: You mean have we tried to simulate a system over time? >>: No, cache result. The run time resolution to find out the list of recipients, find out the keys. >> Carl Gunter: No, we didn't do anything like that. It would be -- you know, it was something we got up to the point where you could actually just use it at the University of Illinois. But if you really were going to use it, you'd have to make this a lot more streamlined. It's like using PGP. It's very, very clunky and tiresome, if you use this command line encryption and that sort of stuff. You might have a directory of full of ABM files you would pick the one you need, that's an attachment. That might be a very crude thing that you could do. But another thing that we didn't do that would be obvious to do here is something that dynamically gets the keys based on what your messages are. So, in other words, you don't go and try and fetch these keys, or something that compromises. Maybe it prefetches the keys at night or maybe it just gets them on demand, like you get a message and you say I can't decrypt that until I get these keys. Or maybe it does both. Like some combination of those. But we didn't try to do any of those kind of experiments like with all of us trying to use ABM and see what was the most frustrating thing about it or anything like that. Oh, another thing I'll point out to you is that you have a distinction between what I would call voluntary and involuntary attributes. So you might have like an interests database and people could enter interests in it. You could route on that database. And you can imagine combining that with databases like gender and the HR database which you view as an involuntary thing so that a kind of pragmatic thing, like if my group wanted to do it we would be tempted to have just a voluntary database to do it. If you wanted to make it effective for kind of CRM enterprise like applications you would have to have involuntary attributes be available. >>: Couple times you talked about the possible trade-off between the reading permissions versus the receiving. I'm wondering if I misunderstood you. If you made the reading scope larger than the receiving scope and then the message gets somewhere else, another mechanism. Then someone who shouldn't be able to read it can, is that ->> Carl Gunter: Absolutely. Let me give that medical example again and explain it. Suppose you have an organization and the rule in most hospital organizations is that all the doctors have access to all the patients. The reason being that they can't tolerate -- the privacy risks, they don't have any cost for, or very little cost for. But if a patient had an emergency and the doctor couldn't get their record, they might get sued. So the decision is that the doctors have to have access to everything. On the other hand, if you send a message, then they might do something like have it forwarded to Gmail, in which case you definitely don't want the thing to go in Clear Text. So you need to encrypt. But you don't have to encrypt anymore than the policy that they would get by going to the system and trying to gather the data directly. In other words, you don't need the push policy to be a different from the pull policy. Because if there was a reasonable pull policy, then the push policy should be okay. So this push policy in this case is the reading policy. >>: Thanks. >>: Your value for your attributes, are they assuming a single value for each attribute, or is there something like a person could have five states? >> Carl Gunter: You could have -- I'm not sure, you can have enumerated ones. It can support enumerated ones. It can support boolean's enumerated numerical ranges. >>: If you only had half of the states, like you control access by state, you say this person gets 10 states ->> Carl Gunter: I'm not sure I understand the question there. >>: If you don't get -- it's kind of a dynamic working question. And it's if you get a subset of the whole, how did you allow for that where you could say attribute name with a list of values and it's not a full set. >> Carl Gunter: Oh, okay. We don't have -- well, we don't have very much by way of like type checking in the system to verify that you're writing down something sensible. Like you could write -- you could send messages to empty sets. You could write down something that couldn't possibly be the case and you wouldn't even know. So, right, so you might imagine the system -- we did consider various versions in which the user would get some feedback about the, what you're actually talking about. Like I wouldn't want to think I have a message sent to 10 people that's actually being sent to 10,000. So there's some risk associated here with users misforming the queries and having permission to do it or forming queries that don't make any sense. Like they have combinations of attributes that can't occur. >>: So you have a example, the attributes come before an HR database, which is controlled by (inaudible). But who can send e-mail to whom is controlled by a different set of people. So how do you guarantee that if we're admin we're not intentionally or unintentionally creating attribute barriers therefore people are changing ->> Carl Gunter: A partial inspiration for this, and this is one of the things we were interested in, was there would be policies that people could manage. And part of our inspiration was that the HR department of the University of Illinois has a mapping like this already. But it's for the pull database, not for the push. In other words, if you have this HR designation, then you're allowed to get access to these HR records. The thought was -- they had a little informal thing saying here's our rules about like if you're an administrator in the computer science department. You have access to the HR records of the computer scientists, that kind of thing. Very much like attribute-based policies. In fact, they are attribute-based policies already. And they have a list of these things and we got to look at the list. Our thought was let's try to see if you can encode these kinds of rules. So you could imagine that the HR people would run this and they would say well here's a set of pull rules. So those could be push rules. So I don't know if they'd be the same. It's not impossible for them to manage. It is fair enough to say this thing of how are you going to manage these rules seems pretty interesting, but that's like true for any of these attribute-based systems. If it's not an explicit list of people who have permission, then it's more -- there's some challenges with that. >>: One hopes it's at least better than having maintaining lists. >> Carl Gunter: Yeah, I think this is the kind of broad agenda I was really hoping to try to push together today is the next generation of these technologies will have languages and analysis techniques and algorithms that allow us to avoid explicit extensional lists and start to incorporate more of the informal management decisions into the actual software. >>: Is it more like doing what-if analysis, say I'm picking up what to (inaudible) deliver it? >> Carl Gunter: We didn't because we thought, it seemed like the thin end of the wedge for questions about privacy. So maybe you can have a rule saying nobody could push to anybody they couldn't pull from. So, in other words, you would make a risk management decision that they could have gone and found that in the database themselves. That was part of the inspiration, too for using the list from the HR guys, saying anything you could have got access to by other means we'll let you do it for the dynamic mailing list. So, yeah. >>: Okay. Thank you. (Applause). [One hour 20 minutes]