|
Virtual Seminar Tech Talk Series
Middleware - Authentication, Authorization, and Directory Issues
June 3, 1998
Participants:
Judith Boettcher (JB)
Jeff Ogden (JO)
Ken Klingenstein (KK)
|
To find a specific term or phrase from within this transcript, use your browser's search function.
JB: Welcome to the CREN Expert Event Webcast and to this session with Ken Klingenstein on Middleware Issues: Authentication, Authorization and Directories. You are here because it's time to discuss the leading core technologies in your future. This is Judith Boettcher of CREN, one of your hosts for today's session, and Jeff Ogden from MERIT is filling in for our regular co-host, Greg Marks. Welcome back, Jeff. You were here with us with Ken about two months ago, weren't you? JO: Yes. I'm pleased to be here again, and I'm actually looking forward to the conversation with Ken. I enjoyed it last time. But I'm also looking forward to the topic since I'm doing some work here for MERIT and the University of Michigan related to password security, and I think that'll fit in nicely. JB: It certainly will. Again, I'm anxious to have us all become more enlightened on how these issues actually relate to one another. As a reminder now, our guest expert, as I said, is Ken Klingenstein, and he is the director of Information Technology Services at the University of Colorado at Boulder. Ken will be talking more about some of these same issues at Snowmass this August at the Seminars for Academic Computing. Welcome back, Ken. KK: Thank you, Judith. Glad to be on with Jeff again, and I think my only claim to fame in this area is that I've failed at a number of attempts at authentication and authorization, so it's good to be able to show the wounds if nothing else. JB: Well, you know, there have to be those scouts that always go out ahead of everyone else, right? JO: You're certainly not alone, Ken. JB: That's right. Jeff, you want to tell folks how to ask Ken questions? JO: Sure. Today, folks who are listening in to this session can send electronic mail to Ken. That address to use would be expert@cren.net. Ken will respond to many of the questions as they come up during the session, but if we don't get to all of them, we can respond to some of those after the fact as well. Let me also remind you that if you miss one of these webcasts, you can pick up an archive version from the CREN Website. That Website is at www.cren.net, and transcripts from earlier Webcasts are available on this site now.
JB: Very good. Ken, let's go ahead and get started on our session on middleware issues. It might be a good idea to start with the term itself that we have in our title -- "middleware". I think that's a fairly new term for many of us. Can you clarify just what middleware is and perhaps what is it in the middle of? KK: "Middleware" is one of these embracing terms for all of the glue that links applications to the basic operating systems and underlying infrastructure of the institution. Middleware takes the individual instances of descriptors of who-you-are and what-you're-allowed-to-do and your personalized information, and middleware takes this from individual instances to an enterprise-wide service. In doing so, it provides you with your needed personalized information, hopefully regardless of location -- hopefully regardless of what workstation you're at, what system you're using. It tends to tie things together. One of the unfortunate aspects of the term middleware is that it has given rise to the term "underware", which generally now means those really deep applications like domain name servers and network time and the stuff that you should never, ever see that holds things together. On top of middleware, you would find things like browsers that might want your digital certificates, TelNet programs that might want you to have an authenticated login, directory programs that might provide other folks with pictures of you or descriptions of what roles you play at the institution, etc. JB: Okay, so in terms of middleware, it sounds as if it's a set of services that really have been evolving over the last five years or so. We didn't worry so much about having these kinds of things in place a few years ago because we didn't have the Web in place five years ago. KK: Yeah, I think that, in fact, the rise of middleware is a direct result of the increased use of computing and the increased variety of uses of computing, so that you don't want to have to enter your password in 19 different programs that you may want to access during the course of the day. I think "accounts" is an interesting measure of this. It used to be five or six years ago that I just had one account, but now I have accounts that manage my lists and accounts that manage my access to library databases. I have accounts for various systems around campus. I have an account for my LAN and an account for my e-mail system. That's more accounts than I can manage, or at least it's more passwords than I can manage, so I want to have a mechanism for a single logon. JO: Even more important, you expect to get more accounts in the future to deal with things that aren't even on your campus? KK: Yeah, that's a good point, Jeff. I think that you can lump "middleware" as a way for us to control the complexity of the environments that we're developing.
JB: Actually, that just leads us into perhaps what we would like to do for the folks today, Ken, and that is the issues that we're talking about today are really inextricably linked one to the other -- very much like either a house of cards or maybe LEGO sets. There's just a whole set of complex interdependencies. Would you like to kind of give us a road map of where we're headed today? KK: It probably begins, Judith, with making sure that you have some kind of unique identifier for all of the users on your campus. That unique name is going to be the index into a variety of information services. Once you have created unique names, which is as much a social process as it is a technical process, then you ask the followup question: How do you prove that you are, in fact, the person associated with that unique name? And that's what authentication is all about. Once we've established that you are that person and that you are authenticated, we can then ask the question: What can this authenticated person do? And that is generally in the category of authorization. Once we've got those two pieces in place, then we can start to talk about where do we keep some of the information about this unique name -- about this unique person? And that really gets us into directories and mechanisms for storing that information. I think the final step in the sequence (and I don't know that we'll get a chance to explore that well today) is how can these unique names receive wonderful customization services automatically? How can we do mass customization, which I think is the name of the game in years to come.
JB: That's interesting. With that mass customization, you actually link us right back, then, to the very beginning, which is the unique names. So in fact, we would have a completed circle, so to speak. KK: Yes. And if we want to start thinking about what is that unique name, frequently it is your login name for a particular account. And we try to assert that those login names are unique across the entire enterprise. You may want to use something else as your unique identifier -- a social security number, an e-mail address, assuming those are unique. But one way or the other, you need to have a differentiator in there that begins the process of identifying who somebody is. So if you happen to already have a unique name space for campus, you're well ahead of the game. If you're not, you need to think about how can you link together duplicate names across campus and customize those down to individual instances. At some universities, you may begin by saying, "Well, there's 35 hosts out there and users on those 35 hosts all have logins that may be distinct for those hosts, but may not be distinct across campus. How can I reconcile that?" You can introduce a network identifier. That's been the case at a number of universities where we give you yet a new identifier, but this one we guarantee to be unique across the campus network. If you do that, you need to add value into that network identifier. You need to have a reason for it, and you may use it to control access to the campus modem pools or access to other campus-wide resources. But one way or the other, we need to take a set of (inaudible) of names that are out there on the campus and build an overarching name space to begin the process. JO: Ken, that's what we've done here in Michigan across many institutions -- not even within a single institution -- where people have taken things that look a lot like e-mail addresses. My e-mail address is jogden@merit.edu, but my login identifier is also jogden@merit.edu. So if there happened to be a jogden at Wayne State University, they would be jogden@wayne.edu and so on. That same scheme can be used within a campus. It could be jogden@math.wayne.edu for somebody in the math department, and somebody else could be @biology.wayne.edu and so on. KK: Yeah, it's an interesting point, Jeff, that what you choose as your unique identifier may be dependent upon what the application du jour is, and that we go back -- Our unique identifiers at Boulder are, in fact, your login name because we began at a time when logins were the coin of the realm. Now that e-mail is very widespread, users will understand that as a unique identifier as well, and will be able to differentiate their e-mail name from their login name. Since my e-mail name is ken.klingenstein@colorado.edu, I'd like to avoid typing that frequently, which is why my unique identifier of kjk is really appealing. JB: Okay. So in other words, the very first step that any university needs to be doing (if they aren't already) is figure out some kind of a schema to insure that everyone in their community can have that unique ID. KK: Exactly.
JB: Let's say that we've got that. What happens next in terms of moving towards these authentication schemes? KK: Well, the question then becomes how does one establish electronically that one is the person associated with that unique name. And typically, there are three categories of schema that are used out there. The first category is something-you-know -- most typically a password. The second category is something-you-have -- and that could be a smart card that is generating unique passwords that you can use to login, and only you have this smart card. There's another scheme called "S Key" where you have a locating list of passwords and you carry around that list of passwords on a small 3x5 card and each time you use one, you cross it off and you move down to the next password -- and the systems that you're trying to access also recognize that one password has been used up and you move to the next. So that's a case where we've taken something-you-know and replaced it by something-you-have. And the third category (which is just beginning to develop) is identifying you by something-you-are, and the whole interesting class of biometric authentication devices are likely in the very long term to be the predominant way in which people identify themselves. It might be a fingerprint. There's some interesting work being done at MIT where it's retinal scans, and you type your name and then you look at a camera on your computer. A retinal scan is taken and matched against the file of retinal scans, and you may be authenticated. JO: Today, the reality is that only the first of those is really widely used, simple passwords. Is that a fair statement, do you think? KK: I think so, Jeff. And we may see this develop rapidly over the next few years, but simple passwords have been around for a long time -- and indeed much of the development today is on making simple passwords more secure. JO: The beauty of simple passwords is that they're inexpensive. You don't have to have any extra hardware or all of that. They work almost anywhere. The disadvantage, of course, is that they're not terribly secure. People pick unfortunate passwords that are easy to guess, or the passwords might be sent clear over a network and so on. JB: Your point, Jeff, on the extra hardware, I think, is an important one -- at least for the short- to the mid-term -- so that if one has a keyboard, you can actually then import a password. Although the technology, again, is getting better with even the voice input -- maybe another one that might be coming down the pike. JO: Also the smart cards where what you do is you type what's shown on a small digital display on the front of the card and so on. There's an expense for that kind of thing, but it isn't the major expense of being able to plug in your card into every single computer that you might want to use. JB: Right, I know I had one of those for awhile, but I was always so afraid of losing it. It was heavier than some of the other multiple 25 cards that one carries around with oneself. KK: The expectation on this is that we will increasingly move to some kind of credit-card device that has a chip built into it that has, perhaps, your digital certificate in there as an authentication mechanism, and then you would just swipe the card at a computer when you want to authenticate. That presumes that there's a swipe at the machine, and that's not the case today. JB: Right. So just as they're putting in Zip drives and all, it might be again in the long term that machines and other devices would become more equipped with that -- with a swipe, right? KK: I saw a floppy shell the other day where you slip your chipped card into the floppy shell and put it into your floppy reader and it reads off that. So there's a lot of work being done in this area, and when there's a lot of work being done, you can always assume two things: that there will be innovative new solutions, and they'll be inconsistent. JB: Okay. JO: At the University of Michigan, we've concluded, however, that we have to do something like this for all users that have access to any data that they or the institution considers to be important -- that multiple-use passwords of the traditional variety aren't enough for some applications and some users. So we definitely have to be pushing in this direction, and it's great that there's new things coming along. It will make it easier to do that.
KK: In fact, what this discussion highlights is that there's a couple of ways in which the university's need for authentication differs markedly from the corporate sector's needs, and so it's not clear that we're going to get the marketplace to produce the kinds of answers we need. Let me give you several instances of that. One instance is that we've outsourced our modem pools on a number of campuses, and so we have dial-up users who want to get access to institutional resources that may be authenticated by an IP address. And now when you go in through an externally provided modem source, you don't have the right IP address. That's a case where the corporate world generally tends to own its modem pools and ensure that the addressing is consistent with the internal IP addresses. We have that as a problem. The converse of that, in terms of library access materials, is also unique to Higher Education. Frequently, anybody who comes into one of our libraries (and this is especially true at land grant institutions) has the right to access our materials, so we may need to give a temporary identification to somebody, and a temporary electronic identification to somebody off the street so they can access library materials. Again, a problem the corporate sector may not have. The third distinguishing factor -- and again, these all relate to mobility, interestingly -- is that digital certificates are an exciting new technology for a number of security goals, but digital certificates are currently stored on the hard drive of the machine that you're working on. In the corporate sector, since you work on the same machine all the time, that's not a problem. But in the public labs of Higher Education where we have itinerant students walking in and out, we need to find a way to have their digital certificate appear on the hard drive that they're currently working on and then go away when they leave that machine. That mobility problem is not being addressed well by the commercial sector at that point, which might require us to actually roll our own solution.
JB: Can you perhaps go back and link the authentication process to the digital certificates, Ken -- so are you saying that once I manage to use a unique name and I become authenticated, I want to become authenticated to someone else, and the digital certificate is a way to make that happen? KK: Well, there's two good questions in what you just asked, Judith. The first is, what is the loci of authentication? And frequently we just want to do authentication within a particular unit or perhaps on a campus-wide basis. But both of those really can be characterized as Intranet types of authentication. And as long as you're working within a single province, you tend to have more control over the possible solutions. We will also need an interoperable authentication process -- one that will work between disparate institutions -- and there are at least two drivers for that interoperable authentication schema. The first driver is Internet2, which will likely require some kind of end-to-end authentication mechanism for a number of the services that we're looking at. In particular, Quality of Service may ultimately require an end-to-end authentication before we dedicate bandwidth or quality services to a particular user. Another arena that is driving the need for interoperable authentication is with library databases. Most vendors of scholarly materials would like to move from the IP address scheme that I alluded to earlier to some kind of more refined scheme that allows an authorized user to login regardless of which modem pool they may have dialed in through. And those library vendors really just want to program in one schema, so they'd like all of us campuses to please adopt the same schema to make their life easier. By the way, that library example which is talked about quite well in a white paper that CNI has recently done and can be found on the CNI website -- JB: And I think we put the URL on the website for this event as well, Ken, so people can just go ahead and take a look at it there. KK: Yeah, what Cliff Lynch has done in that paper is to highlight the fact that while we may want detailed authentication information in some instances, we may want to hide some of that information in other instances. For example, libraries have a long history and even, I think, a legal protection to not reveal who is accessing which materials. So if we have an authentication scheme that is built on a highly personalized piece of information, then library vendors will know exactly who is accessing which materials, and that may violate some privacy constraints. So even as we learn how to do detailed authentication, we may need to find ways to hid some of that detail in instances where it's not appropriate to convey the information.
JB: Do you want to say anything more, Ken, about the need for Higher Ed perhaps to adopt some kind of a common schema so that it would make it more realistic for the vendors of scholarly materials to work with us? KK: The challenge right now is that there are only two tools that are available to us. The first tool is called Kerberos, and it's been around since 1983, developed at MIT. Kerberos is a fairly simple but secure method of conveying passwords in encrypted fashion to stop sniffing, and Kerberos has the second benefit of providing us with general single-logon services -- that is, you'll log on once and get authenticated, and then you wave your authentication ticket to various other services around campus, and depending upon your credentials, you will be allowed in or out of various services. So Kerberos is out there today. It's going to get a distinct boost by its inclusion in NT 5.0, which will make it more of a de facto standard. However, it has problems in other areas. It can't be used, for example, to digitally sign e-mail or to encrypt e-mail. A tool that was developed for that purpose is called X.509, and that's the digital certificates that you may see in Web browsers today. And there's a lot of interest because it's an open spec -- because it's a good protocol in seeing how far we can apply X.509. As I indicated earlier, with the idea that your X.509 certificate has to be present on the computer that you're working on, it poses real problems for Higher Ed. X.509 also doesn't perform particularly well, and so it's not clear you'd want to use it to encrypt large data streams that are proceeding at high speed. More than likely, the answer to what authentication schemes -- what security schemes we're going to use -- is all of the above. JO: Ken, that suggests that we're going to have to deal with at least two and maybe more schemes on our campuses. KK: I think so, Jeff. I think we can probably sort these out into a set of schema that we'll use on campus, which will be more than likely Kerberos for a large number of applications -- authenticating to your e-mail, authenticating to your local LAN server -- and we'll use 509 for e-mail encryption. And we'll probably use 509 for most of our external authentication needs as well. JB: Jeff, I think we've got a question that has come in. Would you like to share that with Ken? JO: I actually don't see the question on my e-mail list, so I can't do it. Sorry!
JB: Oh, you don't! I don't' know why you didn't get it. Ken, we have a question that has come in from Don Miller from the University of Pennsylvania, and he's the Information Security Office there. He's asking to what extent do you think that VPNs make use of traditional reusable passwords safer, or asking it another way, if all of the network traffic is encrypted, then how big of a problem is it that the password is reusable? KK: Good question, Don. Boy, if we can get to the point where all of the e-mail -- all of the network traffic -- is encrypted, we'll have gone a long way. But it's not likely that we'll get to that point. One of the interesting drivers for encrypting network traffic is something called IPSEC (IP security) with the new standard being promoted out there. And while it's very appealing, IPSEC has problems when you get to firewalls -- when you get to network address translation devices -- and IPSEC evidently has a significant performance hit. So much as I'd like to believe that we're getting to VPNs and to secured transit of communications on networks, I think that the developments on the right hand (which are getting our networks to perform better) and the developments on the left hand (getting them to have encrypted traffic) are probably at odds with each other. JO: My own feeling on this, too, is that we should encourage encrypted data over networks -- either at fairly basic levels such as IPSEC, or perhaps at some higher levels such as secure shells or TelNet sessions. But you're often going to find yourself mostly perhaps working in that secure environment where everything's encrypted, but then occasionally, you end up somewhere else that's outside of that environment. You don't have control over the software and the machine, but you want to use the 'Net -- you want to access some resources, and so you're going to be tempted to type in your password. It'll go in the clear, and if somebody happens to be watching at that moment, all of your other security is for naught because you've just been compromised. So having the one-time password scheme protects against those cases where we're drawn outside our traditional environment. KK: Good point, Jeff. I think that for all of these schema, given the amount of mission-critical activity that we're doing on networks today, you can't have too much security.
JB: Ken and Jeff, I think we're running up to about 4:30 here, and I think we really want to ask and focus on questions on authorization. Once we are actually authenticated, how are we going to start managing just the full range of questions as to what am I being authenticated to do or to access or to be, actually? KK: If authentication is the 800-pound gorilla, then authorization is the 35,000-pound elephant walking right behind that gorilla. JB: But that elephant has gotten even bigger, hasn't it? KK: And partially because of the payload that that elephant carries. Authorization is going to be the underlying prop for almost all of our electronic work flow. And given the amount of work flow that we have today, we all believe that there's a huge payoff to be had in converting all of the documents we sign and all of the forms we fill out to an electronic flow. To do that, we're going to need to know where does this form go next for approvals? We're going to need to know who can purchase off of this account and what are their limits in doing that? So authentication gives us security. Authorization opens up a lot of future doors to us. If we're struggling with how to do authentication at this point, we are really early in the game of authorization. We don't know quite how to do the authorization in the first place. This is a fundamental question that universities are wrestling with as they go through business process re-engineering. Is authorization done on the basis of individuals or positions? Are you authorized to approve purchase orders of less than $5,000 based upon the fact that you are an Administrative Assistant II, or based upon the fact that you are Judith Boettcher? And typically at universities we have tended to designate approvals and authorization on the basis of who you are. And that is not a particularly scaleable approach. Though much of the conversation is: can we move to an authorization model where approvals are based upon positions and then we'll have a reasonable way of encoding that. When that argument is advanced, other schools come back and say, you know, one of the unique things about Higher Ed is that we wind up doing all authorizations on an individual basis. That the new department chairman asks the old department chairman to continue to do Approval Form Y while the new department chairman gets his feet on the ground. So we have to go back and have that old department chairman -- now on the basis of not being a department chairman, but on the basis of who they are -- have an approval and authorization that they didn't have otherwise. This debate is raging fiercely. I know that Michigan is opting, hopefully, for the side of authorization-by-position. But one school that's been far down this track, so far, is MIT. And they've come to the opposite conclusion that the only scheme that will work is authorization by individual. And what they've proposed, and in fact have created, is a software system that is called Roles. Roles has a -- JB: Is that R-O-L-E? KK: R-O-L-E-S, right. And what happens is that when you get a new employee, you sit down at the Roles database and you go through (hopefully within less than two days) a list of all of the possible authorizations that exist in the institution and which of these authorizations at which levels and with which modifiers the new individual can function at. Once this profile is established, MIT will then use it to download information into all of the systems around campus -- in a single nightly update enter this person into the electronic realm of authorization. It's an interesting approach. We have to track this and see which way that we go.
JB: So, it's our new electronic life of keys, rather than getting real physical keys, we're in there -- KK: Precisely. This is our profile of the future. Now when you raise the metaphor of keys, you raise the question of where do we keep this authorization materials. And that's another open question. One of the places that you can keep them is in directories. Another place you can keep it is in some kind of profile on the hard drive, or perhaps in that smart card that we were talking about. Microsoft has taken the Kerberos-ventication (phonetic) scheme and added the ability to contain authorization information inside the authenticated identity. So that's yet another place where we can keep authorization information. And we're at the point -- JB: So where exactly is that again, Ken? You said that Microsoft is -- is this part of the NT implementation? KK: Right. That in NT 5.0, when you authenticate, a Kerberos ticket will come back to your machine and it looks like a normal Kerberos ticket except embedded deep inside there is a list of authorizations. And so we've returned not only who you are but what you can do. JB: Let me just remind folks out there that are listening that it's a good time to ask Ken some additional questions and you send your e-mail questions into expert@cren.net. And going back -- did we get your question answered that you asked earlier about encryption? Okay. Jeff, did you have another question following up on either the authorization or the directory where Ken was going? JO: Well, I was just thinking a little bit about the roles -- the things that are associated to you as a person -- versus the things that are associated with your position. Ken, let's say that I had a bunch of students that are allowed to access an off-site database that's provided by some database publishers. And I put all that information in as individuals when they enroll, and so on, but two years after that I sign up with a brand new -- my institution signs up with a brand new database publisher. I somehow have to go back and add the new authorization for the new publisher for all of those students, and I'd better somehow know that they're all students, shouldn't I?
KK: Yeah, Jeff. You're pointing out, again, one of the unique things about Higher Ed is that not only do we find new vendor relationships frequently, but we have staggering turnover in our customer database. Now we can keep these students back for a few years and try to get a little extra tuition out of them to boot, but it's not in service to our customer base. So the fact that we have almost complete turnover every four years suggests that we have issues of scaling that the rest of the world does not. JB: So that means that if we're going to make this happen and we're going to consider storing these profiles in directories or other places, how does one go about determining which strategy or directory strategy that one might want to think about using, Ken? KK: Well, let's see. Two comments on that, Judith. Ultimately the marketplace will decide, and one of the major factors there will be performance. But there is a standard Internet-based directory protocol call LDAP (Lightweight Directory Access Protocol) developed at Jeff's alma mater that is likely to be the universal language for accessing directory information. So LDAP is an elegant protocol, reasonably lightweight, extrapolated from X500, which was a very odious and heavyweight protocol. And LDAP not only can access directory information, but it does it in an intelligent fashion. The various fields inside the directory have attributes associated with them that describe the type of data being held in this particular directory element. For example, you may have stored a picture of yourself in the directory, as well as your favorite bookmarks, as well as you e-mail address, as well as your digital certificate. Well, a program that knocks on your directory server looking for a digital certificate will get one and know what to do with it because it asked for a digital certificate, whereas another program perhaps looking for your photograph would ask for the photographic element, receive something that's a JPEG and know how to handle that appropriately and display the photograph. So LDAP is rich in its ability to handle multiple data types, it's extensible in that you can describe new data types and in a self-describing language and make that widely accessible.
JO: Ken, in addition to LDAP, what are some of the other alternatives? Or is that the only solution out there. KK: Well, assuming that Bill Gates is not listening, we can identify active directories as the approach that Microsoft is taking. And active directories has some interoperability with LDAP, but there's a few things that it does differently. And so how it will work with LDAP I think we have yet to see, but we should know those answers, I would guess, within a few weeks or months. Another need that we have is to begin to standardize the kinds of information that we have in these directories so that you know that Higher Ed has agreed that we be populating our directories with a minimum set of information -- that certain information will be excluded from directories because of Higher Ed's unique aspects, like ferber. And then the last problem that we have to work through with directories is now that we have the information in there, if the user needs to update their own personal information, how can they securely do that? And suddenly we're back at authentication. How do you authenticate yourself to the directory server so that you can change your personal data. So how will directories do authentication? I don't think we know the answer to that now. They will contain keys that will allow you to do all kinds of other authentication in the external world, but how will they be -- how will you authenticate yourself to the directory?
JO: But what we can say is that people who learn about directory structures and those techniques and even begin to implement some on their campus will probably be a little bit ahead of the game as they start to build their own services. Because at least they'll have a place to put this kind of information as we figure out how we're going to use it. KK: Good point, Jeff. And if we're looking for some safe bets -- a caveat that I bought oil stock when it was very high -- JB: And so we should really listen to you on this. KK: Definitely, on this one. But I think LDAP is a safe bet. You can get LDAP servers from the University of Michigan where there is a UNIX code freely available, and you can get LDAP servers from Netscape as part of the Netscape server environment. And it is certainly reasonable to do beginning developmental work in LDAP. I think another reasonably safe bet is to invest in a Kerberos infrastructure. Once you have Kerberos its a very low-maintenance item that gives you some level of comfort. I think digital certificates are certainly going to be a part of the long-term picture, but the general phrase that I've heard is that right now digital certificates are half-baked and let's just hope that the oven is still on. JO: That corresponds to the things that I'm hearing and believe myself -- that digital certificates are actually a very promising technology, and so on, but today there's an awful lot you have to do on your own, an awful lot of the work you have to assemble some piece parts to make it work. Kerberos, while it may be more limited in some respects, is more of a complete solution for those areas where it is strong.
KK: As long as we're giving people acronyms to be armed with, one of the acronyms to be aware of with digital certificates is something called the PKI, the Public Key Infrastructure, And it's the way in which people can exchange digital certificates in a trusted fashion. It will probably make sure of LDAP, but we don't quite know how to do PKIs and that's an area of great interest at this point. How do you revoke a digital certificate when the user is no longer associated with the institution? That's a typical question. How long should a digital certificate live? If you've used digital certificates to encrypt all your e-mail, and then you've lost your digital certificate or changed it, how can we go back and unencrypt that e-mail? How long do we need to archive old digital certificates? These are all questions that are right in front of us that we don't have answers for today.
JB: Ken, we've got actually Dave Miller came back with a couple follow-up questions. And let me give them to you both and then you can answer them in the order that you think works best. One question has to do with standards, and he's asking whether you think that either PGP or FMIME will emerge as a standard for e-mail security, and would there be any hope for interoperation on that? That's one question. And then the other question links back to the traditional prophesies for faculty, staff and students presenting themselves in "person" to obtain their campus card and network account -- and obviously with distance learning that's a little hard to do, so any thoughts on how universities are authenticating distance-learning students? And I'll let you answer whichever one you'd like first. KK: Well, again, Dave has excellent questions there. Regarding the first one, PGP was an early contender. It was felt ultimately that its inability to scale, its inability to exchange PGP information seamlessly was going to be a real handicap, and people turned at the point to X.509 as a legitimate alternative. In the intervening months a couple of things have happened. One of the things is that PGP went International -- it moved off shore, and in doing so it resolved a number of the export controls that some of these other schemers are still subject to. And that's made PGP more appealing. Secondly, its developed a crude schemer for exchanging PGP information, and that creates something similar to a PKI infrastructure for PGP. Lastly, X.509 just received a significant setback in that one of the companies that has been driving this is Entrust. And Entrust just got some patents approved for some of the internal schemer for X.509, and that which was once part of an open standard got wrenched out of it a few months ago and is now proprietary and patented. So I think that illustrates that the marketplace in this may be a force of divergence versus a force of convergence. And we may go back to PGP because it wasn't light, but it wasn't scuzzled by the elbowing and unseemly behavior of companies trying to patent technology. JO: To a large degree what will be successful will be determined in the marketplace when there's a critical mass of other people that are using the same scheme that you are, or that you might adopt. But it's also a chicken and egg problem because you're trying to predict that. If you narrow the scope of the problems to just your campus or just your department, and so on, you can probably work with enough users to agree on what's going to be used. In that kind of environment, PGP could work quite well -- certainly as a stop-gap while you wait for the rest of the world to figure out what its doing so that you can do the same thing.
KK: Let me address Don's second question, as well, of how do you physically establish the correspondence between an individual and their digital certificate -- and again point to MIT, when in fact they use Kerberos to bootstrap the digital certificate process. And they assume that you have your Kerberos password and that you've received that by a human process. And then you can go and step to any keyboard at MIT and use your Kerberos identity to download a digital certificate. I think that's indicative of the way in which the technologies that are seen to be competing in the marketplace are actually complementary when you start to look at it further. JB: Are you saying though with that, Ken -- that example seems to indicate that long-distance students would come to campus at some point, or come to some perhaps alternate or designated spot. KK: Judith, we have far more good questions than we have answers, and you just gave us another one. In this case there are four levels of trust that a digital certificate can imply -- and they all relate to how much identification we saw when we gave an individual their digital certificate. We saw it by passport -- we actually saw them walk in and compared their passport -- down to something like they wrote us an anonymous note on the back of a 3x5 index card. So there are these different levels, and what we don't know is what level of security the various vendors will require of us. So that if we present a digital certificate that was issued at the lowest level of security where we didn't see somebody in person, will that work for purchasing stuff across the Web? Will that work for access to library databases? What restrictions will the vendors place on us in terms of how we assign digital certificates? And the marketplace has got to tell us that one.
JB: Well, again, as you just said, it sounds like we always end up with as many questions as we do potential strategies. Do you want to answer just one final question before we wrap up, Ken, and that is, is there any final piece of advice that you'd give folks right in this whole area of middleware? KK: As hard as it is, is a measure of how important it is -- and we shouldn't get discouraged. We're going to need the stuff. It's problematic that it ebbs and flows, but if we think back five or six years ago, it was very difficult to get an IP stack that would work with netbios in DOS. And we all spent inordinate numbers of hours getting various DOS machines on campus to work in IP, and today it's turnkey. I think we're at the stage right now where its very problematic to do authentication and authorization, but we're going to pass through that problematic period, I would guess, in a very short amount of time -- just because the drivers, the databases, the Internet2s of life are out there and compelling us to solve this problem. I think this is one of those instances where listeners should stay tuned to CREN and follow new experts as they come along as the topics develop. JB: Very good. And with that, Jeff, do you have any final words? JO: No. I think this was a very good session, and I learned something as well as participating. JB: Very good. I'd like to thank all of our web participants for being here with us today. And remind folks to put the next Expert Event Webcast on their calendars. The schedule is only a click away from the CREN homepage. Our next session is two weeks from today on Wednesday -- I think you all noticed that we're trying to standardize on Wednesdays here -- at 4:00 on June 17 and our guest expert on that session will be Russ Vott. And he will be taking questions on the whole area of health disks and strategies for responsiveness and technical support. Again, another reminder, if you'd like to receive announcement messages for these sessions, send e-mail to cren@cren.net. Thank you all for everyone who helped make this possible today -- the Board of CREN, our guest expert Ken Klingenstein, host Jeff Ogden, Brian Bonn at UM online for the encoding and for all of you. You were here because it's time. Bye, Ken. KK: Bye, Judith. JB: Bye, Jeff. JO: So long. JB: Bye all.
|