TechTalks Transcript
Digital Certificates and Identifying Users on Campus
 Greg Marks [GM] |
 Howard Strauss [HS] |
 David Wasley [DW] |
February 11, 1999
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
GM: Welcome to the CREN Tech-Talk series for Spring of 1999 and to this session on Digital Certificates and Identifying Users on Campus. You are here because it is time to discuss the leading core technologies in your future. This is Greg Marks of Merit Network, your CREN host for today. I'm pleased to welcome the Tech-Talk technology anchor, Howard Strauss of Princeton. Howard is a well-known Web and all-round Information Technology expert. Welcome Howard.
HS: Thank you Greg. I'm Howard Strauss the technology anchor for the Tech-Talk series of technology webcasts.
The job of the technology anchor is to engage our guest expert in a lively technical dialogue that will answer the questions you'd like answered -- and to ask those very important follow-up questions. You can ask our guest expert, David Wasley, your own questions by sending e-mail to expert@cren.net any time during this webcast.
If we don't get to your question during the webcast, we'll provide an answer in the webcast archive.
In the 1992 vice presidential debate, Ross Perot's running mate (whom I'm sure you all remember) Admiral Stockdale, introduced himself with the words "Who am I?" For the millions of viewers watching, that was a very good question since they had never heard of him or seen him before. His very difficult task, which he recognized, was to quickly establish his identity to the voting public.
Establishing one's identity is not easy to do. If you were asked to establish your identity to me, chances are you'd reach for your wallet and wave your drivers license or some picture ID at me. But just because you have some pieces of official-looking plastic with your picture and name on them, why should I believe them? If I refused to trust the items you carried in your wallet you'd likely produce your birth certificate, passport, or some family member who would attest that you were really you.
Ultimately, as Admiral Stockdale knew, establishing your identity takes lots of trust. Only if I am able to trust you, the authorities that issued documents that you carry, or the people who vouch for you, will you be able to establish your identity to me. And once you've done that, then -- and only then -- will I be comfortable in giving you the confidential information that your identity authorizes you to have.
Establishing your identify in person is difficult enough. Doing it over the Internet presents many additional challenges. As the dog using a computer in an old New Yorker cartoon says, "On the Internet, no one knows that you are a dog."
But to use the Internet safely, we need to know who is a dog and who is a bank before we send our money off into cyberspace. Exchanging our normal credentials just won't work online.
Even William Shakespeare was struggling with the issue of identity when he asked, "What's in a name?" He obviously never used the Internet. On the Internet names are not nearly enough. We need digital certificates, certificate authorities, directory services, and much more.
Today our guest David Wasley will help us better understand those issues and how to answer one of the oldest philosophical questions, "Who are we?" Well, at least David will tell us how to do that on the web.
Greg, is that you, Greg?
GM: It's me, although I had this sudden urge to bark and dig into a bowl of Purina chow.
The reference to David Wasley is really quite appropriate because he is our guest expert this afternoon. He's from the University of California Office of the President. He's assistant to the Associate Vice President for Information Resources and Communications in the University of California Office of the President. David's responsibilities include strategic planning for the Information Technology and Communications infrastructure for the University of California system.
It is this planning that has David deeply involved with the question of user identity. He has worked with campus networking issues for many years, and since we're late in this broadcast, I'll refer you to the Website to learn a bit more about David. Just to mention that, indeed, we are starting late because a little technology slowed us down at the start. But we'll run the entire session in any case.
Welcome, David, and thank you for coming back to the Tech-Talk series.
DW: Thank you, Greg. It's my pleasure to be here with you today.
HS: David, I know we're supposed to talk about digital certificates and I'm sure we'll get there, but before we even get onto digital certificates and some of the details here, one of the things that I think confuses a lot of people (and sometimes gets me confused) is the issue of authorization vs. identity. Could you say a few things about identity vs. authorization?
DW: Certainly. I think that that is really at the core of what we are going to discuss today because I think that there's a lot of confusion about what it means to authorize someone to do something and what authorization actually is.
Let me put a framework around this by saying I will try to draw analogies from our everyday existence as much as possible because I think we understand things that we deal with every day. And what we are trying to do in the digital world -- this virtual world that we're building -- is to create similar mechanisms but make a use of the technology and the structures that we have available to us.
So I'd like to draw an analogy, then, of authorization and identity. Identity per se is simply a way of associating attributes of various sorts of things like your name and where you live and what role you have in various contexts with a particular physical human being. Authorization is the process that a service or a service provider goes through to allow you as an individual to do something, or gain access to something, or have something.
HS: David, if I could just hop in here (which I'm probably going to do a million times). You said identity enabled us to find out who a particular person was or who was associated with a particular person, but a lot of times, I want to know who an organization is -- a bank or something like that. So don't we mean something broader than just identifying a person?
DW: Yes, of course. And in fact, banks have identities. Corporations have identities. In fact, they are legally separate entities from the human beings that happen to work for them.
HS: I mention that just because banks and organizations don't have some things that humans have. I mean, humans have retinas and fingerprints and social security numbers, and banks and organizations tend not to have those things.
DW: Yeah, so biometric identification would not work well for a bank. However, if you look at it in the abstract, we're trying to understand whether an entity of some form is associated with particular attributes that we care about.
For example, is the bank the bank that has my account in it? Is the bank the one that I want to borrow money from? Is the individual who is presenting a credential the person who's a professor in the physics department. So all of these things about identity -- whether it's a corporation or a workstation, a Web server out there that you want to buy something from or a human being, an individual -- all of these forms of identity really boil down to the attributes associated with this particular entity, whatever the entity is.
So to go back to Shakespeare's thing, "What's in a name?" Well, a name is an attribute that was assigned to you by your parents. It's one of many attributes that you have. It's a set of labels that you acquired when you were born.
HS: Right, but definitely not your identity.
DW: Not your identity. It's one form, one piece of your identity, perhaps, but it is only one piece. It doesn't really say anything at all about what your role is in the world, what your relationships are with other people or anything. Or, getting back to authorization, it doesn't say anything at all about whether you are eligible to do something. So I'd like to draw a distinction between eligibility and authorization because I think that's also confused. A person could say, "I'm a professor at the University of Arizona campus, and therefore I am authorized to do something." The truth is that that person is eligible to do things that faculty at the University of Arizona can do. Whether they are specifically authorized is up to the service provider.
For example, if it's a payroll system and you're going in to add somebody -- a new hire -- to the payroll system, it may be required that you do that between the hours of 9:00 in the morning and 5:00 in the evening and from a workstation that is on the campus network. So even though you are eligible because of your role at the University, the actual authorization to do it is a function of the rules around that particular service.
I just wanted to emphasize the fact that there are at least three different things that we're talking about here. One is authentication, another is authorization and a third is eligibility. So we can continue the discussion in multiple directions here.
HS: Sure. If I go to identify myself, as I said in my little opening piece, I'd probably go off and use a driver's license or passport or something like that. Now, I understand that if we're going to do this over the Internet, we're likely to use a digital certificate. Could you talk a little bit about how a digital certificate proves that I'm me in the same way that, say, a driver's license or a passport does?
DW: The essence of what a digital certificate provides is that it is a credential issued through some process -- and we can talk about the process itself -- but it's a credential basically that is roughly analogous to a driver's license or a passport. What it implies, of course, is a very important aspect of the credential, and it can be as simple as it implies nothing at all except that it was issued to some known individual or entity and there was a process that was followed to issue it. Or, at the other extreme, the credential could assert eligibility to gain access to certain resources or services. So it is simply a credential, and what you do with a credential really is at the heart of what we're trying to get at in implementing that form of credential within the university community.
HS: But why would I trust that thing? This comes right up to the issue of trust. I wave my driver's license at you -- some people will trust it; some people will demand my passport; some people might demand my fingerprints. What is there about a digital certificate that makes me feel comfortable about trusting it?
DW: Just as with the driver's license, the digital certificate needs to have some validity based on the issuing entity -- that is, the entity that issues your driver's license is the State Department of Motor Vehicles. So we, as citizens of a state, have some confidence that if we see an object of that sort and it looks kind of like driver's licenses are supposed to look, that therefore we can trust it because it was issued by this agency of the state and there's lots of rules around how it gets issued.
Similarly, we have to create rules around how digital certificates are issued -- and have some reason to trust that the authority that issued those certificates followed a known process. If that's not the case -- if we don't know where the certificate came from -- then there's absolutely no reason to trust it. In fact, we shouldn't.
HS: How do we know where it came from?
DW: In the certificate is an identification of the issuing certificate authority, so if it is a certificate authority that you a priori know about -- that is, it is your own campus's certificate authority and you have already decided that you can trust that -- then you can validate that yes, the certificate was issued by that authority. You don't just take it for granted because the name is in it. You actually go back to the issuing authority server and you say, "Did you issue this certificate?" And there's a technical process for validating that it did. So if you already trust that authority and you can validate that it did issue that certificate, then you know that you can trust that credential -- the software can know that it can trust the credential.
GM: So if I'm the J-Store Project and somebody wants to get access to the J-Store resources, that certificate would tell me, for example, that the individual came from the University of California at Berkeley and I would be able to check that and trust that that was a legitimate U Cal Berkeley certificate and give access?
DW: Actually, you're jumping ahead a little bit. The certificate itself may or may not tell you that the individual is associated with the University of California at Berkeley. All you can do at this level we've been discussing is to validate that the certificate was issued by a certificate authority that you trust.
Now, as I said a minute ago, if you already know you can trust it, then your process of validating the certificate is fairly easy. If you don't know that you can trust it, you have to start with some certificate authority that you do trust -- like if J-Store was participating in this and making use of the CREN certificate authority, it would ask the CREN certificate authority, "Do we trust this University of California certificate authority?"
HS: David, it sounds like you're saying that anybody or anything or any entity can be a certificate authority. Can they?
DW: It is very easy to set up a certificate authority.
HS: Could I be a certificate authority if I wanted to?
DW: You could get the software, you could set it up on your own computer and start issuing certificates.
HS: If I started producing driver's licenses, people would be upset with me. So how is me turning out driver's licenses different than me becoming a certificate authority?
GM: The blunt answer is well, who would care?
DW: Actually, there's a number of differences and one of them is you might go to jail.
HS: My concern just is that it sounds like anybody could become a certificate authority. You're just saying that if somebody looks and says, "Okay, this is Howard the Certificate Authority," few people are going to trust that except the people I know very well.
DW: Yes, exactly -- and in fact I would not be at all surprised if there weren't private certificate authorities out there with communities of people that trust each other and they all get certificates so that they can exchanged encoded mail or signed documents.
The reason why it doesn't work in the general case is that there is no way for me, if I received such a certificate, to validate that it is from a certificate authority that I trust unless that particular certificate authority -- the one on your own computer that you set up in your bedroom -- has been registered by some other certificate authority through a process that's well-defined and that my certificate authority can also trust. In other words, there has to be a chain of trust.
HS: So there's some kind of transit of trust going on here?
DW: Yes.
GM: I wonder if it's useful to back up and make clear to people that there is a hierarchy here in the roots of this, as it came out of the university environment, in which there was sort of a presumption that on campuses -- within a campus people will be able to authenticate, and the key driving force was (or a key driving force was then) as people move off-campus, what do you do?
And then you get the next layer, which is the CREN certificate authority, or others like it, which tell you which campuses' certificates are legitimate. Is that kind of hierarchy useful to describe a bit further?
DW: I think you described it pretty well, actually.
HS: Okay, Greg, we'll ask you the next question then!
DW: Within a campus, it is fairly easy to establish a certificate authority that can be trusted by the campus community. The campus establishes offices of record and internal processes all the time. It may be possible, for example, that the Computer Science department would want to have its own certificate authority and have the campus level certificate authority trust it. Well, that's also fairly easy because it's all within the same campus and organization.
It's when you go between organizations that you need a scalable model of establishing transitive trust. And a scalable model means, for example, you don't have individual, one-to-one contracts or trust agreements between each university and every other university in the world. That simply does not scale. And then you start adding electronic commerce, with all the banks and all of the online vendors. You cannot have one-to-one trust agreements with every possible entity that you want to do business with.
HS: Right, so that's why you need some high-level things here.
DW: That's why you need a hierarchy. And you can say, "Okay, here's a community and we all derive our trust from a higher level authority." And then that higher level authority can derive trust from an even higher level authority. And so there will be these multi-level hierarchies of trust, and that's how transitive trust can be established.
HS: One of the things, David, that driver's licenses are commonly used for, as we all know, is to prove that you're an appropriate age for drinking. Along those lines, we probably also know that lots and lots of people obtain driver's licenses (that really aren't theirs) that "prove" they're older than they really are. So a lot of documents that "prove" who we are are easily forged and often forged.
How hard is to do that kind of thing with a digital certificate? What kind of protection is there to make sure that doesn't happen?
DW: Well, it's actually extremely hard to forge the certificate because the certificate itself -- the digital certificate uses very strong encryption, or can use very strong encryption technology. So as I think Jeff Schiller pointed out in his talk last fall, the number of years of computer cycles it would take to actually decode this encrypted object in a useful way is just much longer than anyone has.
So in fact, the mechanism that we are creating by the use of digital certificates is far stronger than the mechanism we have today with driver's licenses or passports or anything else. They are extremely hard to forge.
HS: David, we have a question that came in through the mail from Peter Day at Emory University. I'll read you the question and you can comment on it. Peter says, "A Web server can implement login access using its own private password file. However, creating a password file on each server eventually leads to management complexity. Is anyone doing Web authentication using a network authentication service, and if so, what and how are they doing it?"
DW: There are a number of ways of doing it, and I can't say that I know who is doing what, so let me simply describe the technology.
The bottom line really is the business rules around who can access the Web service. For example, in many universities, services are licensed to the whole university and any member of the university community can gain access to the online resource. So really what is required is identifying that the individual trying to gain access to the service is a member of the university community.
With traditional technology, where you had no generalized way of identifying a person, no generalized credential, the only thing you could do was to keep a list of everybody that wanted to gain access -- which as I think the caller is implying does not scale, is an incredibly bulky administrative process.
With the newer technology, with digital credentials, the certificate -- you can accept the certificate. Software exists to do that. So the Web server can accept the certificate, look up (based on this credential) the attributes associated with the individual that holds the credential, and determine whether that individual is eligible by the business rules of the server to make use of the service.
So this is something that then is very generalizable and scales very nicely. You could have two or three -- a dozen or a hundred Web servers on the campus. Each could have slightly different business rules. One could be, for example, for the Physics Department. Another might be for any undergraduate. Another might be for the Chancellors Office. And based on the same credential, if I go to one Web server, it looks for one set of attributes. If I go to another Web server, it looks for another set of attributes and applies the appropriate business rules to its own services.
So I think that the question is a good question. This mechanism allows us to get away from the traditional single file full of individual user ID's (or even the other mechanism which is often used, and that is IP address) as an authentication mechanism. Some Web services look at the source of the request -- the address on the Internet source of the request -- and say, "Is this within the university campus, or is this on a campus that I know about?" That's very weak and not generalizable, and seriously breaks if somebody legitimately part of the campus community dials in through an ISP service provider. Then they look like they're coming from the ISP service provider and the Web server says, "Nope, you're not qualified."
HS: David, we've talked about using these digital certificates to do Web commerce and identify ourselves so that we could get authorization to use various applications and things. One of the areas where people really need to identify themselves is in electronic mail. Are digital certificates being used in electronic mail? How are they being used?
DW: Yes, the digital certificate technology is based on public key encryption which basically -- I won't try to go into a whole technology of it, but there's a pair of keys of very, very large prime numbers that together form the basis for a mathematical algorithm where you can encrypt a document at one end of a transaction, ship it across the network, and then decrypt it at the other end. And through appropriate use of these keys and sharing of these keys, you can both validate that the electronic mail came from the person it claims to, and you can also protect that document from being read by other people.
HS: Does that mean when I sent mail to somebody, I send along my digital certificate?
DW: No, because then that would be self-authentication. You know, you can't say, "Here's an encrypted message and here's the key by which you can decrypt it" and send those both along because --
HS: Because of course it would work!
DW: Of course it would work! "Yes, of course I am President Johnson."
HS: "And I'll prove it because I've sent the key along which (inaudible)."
DW: Right. So the key here, if you will, is that you have public keys. Remember, there's a pair of keys.
HS: A public and a private key.
DW: A public and private key.
HS: Everybody knows the public key. Only I know the private key, if it's mine.
DW: Right. And so the public key is intimately -- it mathematically links to my private key, but the public key is generally available from a wide range of sources. So if I encrypt something with my private key and it is decryptable with the public key, therefore it must have been encrypted with my private key, you see?
HS: I can see how that would work. That's kind of nice. But what does it have to do with digital certificates? Sounds like very little.
DW: Well, the digital certificate is inherently a public key encryption mechanism. When you receive a certificate, you also receive a public and a private key. You can use that public/private key in secure e-mail. And by the way, I should point out there's a difference between signing a document, which asserts that you created it, and encrypting it for privacy. Those are two different purposes, and in fact very different mechanisms.
HS: Could you make the difference clear right now? It's not that clear to me.
DW: Okay, remember, there's a public and a private key. And so I am the only person in the world that has the private key, but everybody in the world can know my public key.
Therefore, if I encrypt some e-mail in my private key, the receiver of the e-mail can certainly decrypt it with my public key -- but then so can everybody else. So I really don't want to do that. That does not create privacy in any fashion.
What I really want to do is encrypt the mail with the receiver's public key. Again, it's a public key so everybody can get it, but I use the receiver's public key to encrypt my mail. Now only the receiver can decrypt it because only the receiver has the private key that is required to decrypt it.
So that works. That creates privacy, but it does not assert that I actually sent the mail because it has nothing to do with my private key. The only way I can assert -- that I can verify that I actually sent the mail is by the use of my private key in some fashion. So what I do then is I create a version of my electronic mail message that is encrypted with my private key. Only I could have created that. Then I encrypt that whole thing with the receiver's public key. Now only the receiver can decrypt the message, so it's private, and once having decrypted the message, he sees that there's this encrypted thing inside.
HS: So he uses my public key which says, "Gee, it really came from you."
DW: Right. Exactly.
HS: With all this encrypted mail floating around here, I think we run into the issue of people storing company documents (and mail really is a company document) and other documents and then disappearing from a company for one reason and another, or getting run over by trucks and things. I understand that the solution to that problem is something called key escrow. Could you talk about that a bit?
DW: Well, first of all, the point you raised is a very important one and people in a position to implement these technologies for business uses -- for institutional uses absolutely have to grapple with this, and it's a difficult problem because particularly in universities, people are very sensitive about intellectual freedom and privacy. And they should be. It's appropriate. But it is also appropriate for the institution to make sure that its business processes are not damaged or disrupted if somebody is somehow unable to decrypt a message.
So let me back up. Remember when I said signing your electronic mail is a very different process than sending a private piece of electronic mail? Signing is a process that happens at one point in time. Receiving the mail and validating the signature is something that may have to happen at multiple points in time. As you point out, there's an archive of mail. You want to be able to get that archive and decrypt the mail later on. The decryption is done with the receiver's private key.
HS: Which only the receiver knows.
DW: Right.
HS: So if the receiver loses his or her private key, forget it. You're saying the encryption is strong enough so that nobody can ever decrypt it.
DW: Right.
HS: That's comforting! We'll never see the stuff.
DW: Nobody will ever see the stuff. So therefore, obviously, the requirement is that if you, the institution, want to insure that you are able to recover that document in case the receiver loses his key or leaves the university or something, you have to escrow, as it were -- put in a vault somewhere the receiver's private key. Not the sender's, but the receiver's private key.
So the distinction is important. We're not putting into the vault the private key of the person who signed the document. Therefore, we're not compromising the signature. What we're putting in the vault is the private key of the person who is receiving this.
HS: Maybe the university wouldn't have control over anybody, even people who work for it, but it would certainly not have any control over people who were sending the mail to the university.
DW: Right. But even within the university, where you might be able to control the behavior of the individual, you don't need to escrow the sender's private key because there's no point in it.
HS: Right, but actually if the two people were within the university, assuming they would send mail to each other, you'd really have to escrow both keys.
DW: No. That is not true. I'll get to that.
HS: Because person A sends to person B, then person B sends to person A so each of those people is a receiver.
DW: There's a reciprocal thing there and yes -- but there is a solution to this problem. First of all, you do not want to escrow the private key because that compromises the ability of the individual that they were who they were.
HS: To sign.
DW: To sign something.
HS: So are you going to suggest that the person should have two different private/public key pairs?
DW: Yes, that is the solution -- that every individual actually has two key pairs. One key pair is used for signing.
HS: And one to encrypt.
DW: The other key pair is used for encryption. You escrow the private key of the encryption pair and not the private key of the signing pair.
HS: Are people actually doing that? I mean, are universities -- I can imagine a corporation doing that. Are universities actually able to get people to do that?
DW: There are very few universities that are actually making use of the technology at this point. One of the vendors of public key encryption technology offers this dual pair as a service.
HS: Which company is that?
DW: I believe it's Entrust. I may be wrong, but I believe Entrust offers this dual key concept. And I think that as vendors of the technology begin rolling this out in wider use and understand the problem, that it will become common. And it does overcome to some exten (but not entirely) the resistance within a university to the use of key escrow.
Now, within the university, I think we have to do a lot of things. One of them is to educate people about business requirements of a university. Just because we have a requirement that university business must be recoverable in clear text for many, many reasons, we also cannot require that everything that a person does is inherently available in clear text. There may be some things that are inherently required to remain secure, and if the person disappears, it disappears. I'm not willing to assert that absolutely everything that a person does within a university or even within a company must be available to the institution in clear text.
HS: Yeah, we actually had a discussion about this in a previous session where we discussed some legal issues related to Information Technology. I think we actually covered that rather ticklish issue as to what's private and what the university has access to.
DW: And that's a very important thing to understand. I'm not an expert in that field, so I won't even try to cover it.
GM: Let me indicate that we have several questions sitting in our e-mail queue, and that if we don't get to all the questions that people are asking today, that you'll find responses either coming back as individual e-mail from David to each of you, or it'll be posted up on the website after the session, next few days -- and certainly just because we haven't answered all the questions, don't be bashful. Send them to expert@cren.net as indicated on the webpage. And with that little note, let me go back to you, Howard.
HS: David, how does all this stuff fit into directory services like LDAP and that kind of thing? You talked about digital certificates just giving you one little bit of an identity, but your identity is very complex. So is there some interface between digital certificates and directories?
DW: Yes, there is inherently an interface in the technology in that one has to be able to look up the public certificates, for example. But beyond that, in the University of California we are building around a strategy that says that in the certificate itself -- in the credential that we issue and that the user makes use of -- is very, very little in terms of actual identity. There is only enough to provide a unique key that can be used to index databases, one or more databases.
HS: By databases, do you mean directory servers?
DW: Yes.
HS: Are you saying that there's a pointer in the thing into an LDAP directory or something like that?
DW: Yes. LDAP is an access method, but yes. Directory servers that can return attribute information about the holder of the credential, so that, for example, if one wanted to, the Registrar's Office could have an online directory server that allowed indexing of students by the ID that is in the credential, which is typically just a string of digits.
So therefore, if I'm making use of a Web service (or trying to), I offer my digital credential as my authentication token. The Web server itself validates this certificate and then takes the ID string that's inside it, goes to the campus directory service and says, "Here's an ID. I need to know certain attributes about this ID. Is this ID a student or a faculty member or member of the university community?" And then the directory server can return the set of attributes that the Web server requires. The Web server then goes through its process of validating and authorizing (or not) the holder of the credential.
So yes, directory services are critical in this process and also very complex.
HS: It sounds like your university has gone quite a way down the road on this, right, so everybody's using digital certificates. Are people using signed mail there?
DW: I wish I could say that we've gone very far down the road and everybody was using digital certificates. That is certainly our direction and our strategy.
At this point in time, we are still developing the technology and the support services required to do this. We have in place at least an initial version of the university-wide directory service with basic attribute information about every member of the university community. We have some prototype certificate authorities in place on the campus in the hierarchical transitive trust structure, and we are beginning to put in place applications that make use of these technologies. But we are by no means in universal production at this point in time.
HS: If there are universities that are listening who are not as far along as you are (or specifically have avoided this thing up until now), could you make some suggestions as to how folks might get started -- and could you say how much this thing might cost once they get this plan in place?
DW: Well, there's a lot of information on our website, which I think is pointed to from the CREN webpage for this Tech-Talk. So that's one place to start. There's a lot of information, a lot of experience shared on the Web itself.
In terms of cost, there's quite a number of aspects of that. One is simply the cost of acquiring a digital certificate authority or outsourcing the digital certificates themselves, and this is an area where the market is changing rapidly. A year ago, if you went to a commercial outfit to try to get digital certificate service, you probably would have to pay anywhere from $20 to $50 or more per credential.
HS: That's a certificate issued by somebody like Verisign?
DW: Yeah. There were lots of reasons for this -- and by the way, I should point out that Verisign offers essentially free certificates, but essentially with no identification behind them. You just go to their website and say, "Give me a credential." The validity of that credential and the trust that one should put in it is pretty low.
What I'm actually talking about that costs significant money is a credential or a certificate that is backed up by in-person identification of the individual -- some reasonable assurance that it is issued to a known individual or entity. So the cost of using public key certificates has come down considerably, but it is still something to be concerned about. Even if it came down to one or two dollars per certificate, you probably wouldn't want to issue a dozen or more certificates to every member of the campus community.
So the cost of the certificate itself -- there's the cost of the directory services that need to go behind it, supporting not only the servers themselves but the collecting of the information, the cleaning up of the information to make sure it's consistent and correct, maintaining it over time. Many campuses have multiple systems that have information about individuals, and they have very little commonality amongst them. So just cleaning up all of the online information so it is available in a consistent form and kept up-to-date is a major expense and undertaking.
HS: We have one more question I'd like to sneak in here, if I could, from Richard Klingensmith at MSU. Actually, Richard, if you're listening, your note was longer than what I want to read here, so I'm just going to take a piece of it.
Richard actually has a question about the use of Kerberos in the beginning of this discussion and perhaps you could comment on that, but at the end of his questions he says, "Could you elaborate on the process of authorizing some services after the authentication is complete? This is a very complex issue here at MSU and anything we could do to simplify the process would help to include creating our own certificate service?" Those were two things from two different areas here.
DW: Right.
HS: And you could handle this last thing about the process of authorizing use of services.
DW: Okay, I'll just say one quick word about Kerberos. Kerberos is a very important technology and actually is a very nice complement to the use of public key certificates in a number of ways.
For example, how do I carry my certificate around with me? There's no good technology around for that yet, although that's coming along. But I could archive a secure server and then use Kerberos as an authentication mechanism to allow me to retrieve it. Conversely, I might in fact use my public key certificate to get a Kerberos ticket for local service.
The real distinction between Kerberos and public key certificates is that Kerberos (I think Jeff Schiller pointed this out) is primarily oriented around a single organization having a very centralized authority and authorization, whereas the public key certificates are inherently a distributed process. It's a credential that one organization can issue and another organization can validate. So that's really the primary distinction between the two, but they're a nice complement to each other.
In terms of authorization and access to services on the campus, again, I think that the important thing is to be able to articulate the business rules. That is, if I have a timesharing system, what are the rules about who can gain access to it? If I have a site-licensed set of resources from a publisher -- for example, McGraw-Hill textbooks -- who is eligible to gain access to it? If I have payroll information, who is eligible to gain access to it? If you understand the business rules, then from the credential and from directory services that allow you to retrieve attributes, you can apply the business rules to the identity of the individual and decide whether or not authorization is allowed.
Once authorization has been granted, then you can use the credential, for example, to identify which account it is on the timesharing system or which entry in the database the individual can have access to (or not). An example here in the university is we would like employees to be able to change things like the number of IRS deductions. If they have a new child, they want to go in and change their W-4 form.
HS: Nice to be able to do.
DW: Yeah. If I move to a different address, I'd like to be able to go in and change my address online, rather than having to submit seven different pieces of paper.
In order to do that, then, I want to assert my identity using a digital credential. I want the system them to validate that yes, I am an employee, currently employed. Then the database for the Human Resources system, that server can use my credential to look me up in that directory and only allow me to change that one directory entry (and in fact, only the fields I am allowed to change as the employee. I'm not allowed to change my payroll, for example -- unfortunately).
HS: Okay, I think we're just about out of time here. However, there was another quick question that came in here. It's kind of interesting and it's a one-liner. Maybe we can try to fit that in. It's from Richard Heine at MSU, and Richard asks, "Where does the student keep the private key if the student does not own a computer and uses only publicly accessible computers?"
DW: That is currently an unsolved problem. There are two ways you can do it today and neither one is very easy. One is you can store it on a diskette, and then --
HS: Have the student carry it around.
DW: Have the student carry around a diskette. Another way which I think is more viable in the long term is use of Smart Cards. Smart Cards have enough memory to be able to store the entire certificate, public/private keys, etc., and in fact will be used for electronic commerce -- a lot of e-cash. And I think eventually all workstations will have Smart Card readers. And that will then become the better way to carry your certificates around.
GM: I think I need to be very clear that there are quite a few questions from folks that we have not answered that will be handled after the session, and unless Howard or David have some last comments --either of you have anything you want to add at this point?
HS: Well, actually, I have about 20 more questions I plan to ask.
GM: This topic seems capable of that, doesn't it?
HS: Given that we're already past the end of this broadcast --
GM: We started late, so we're okay.
HS: Yeah, we're even over given that we started late, but that's fine. It's been most interesting to me and I hope to the people who were listening. We're certainly going to visit this topic again, or a related topic, so I urge listeners to watch our schedule and look at when we cover this and other interesting topics in the future.
GM: I want to say thanks to everybody who has been listening in today and sending us questions, and to David. Please send any follow-up questions, if you still have some, on things that we did not get to to expert@cren.net. David will answer them, either individually or on the Web.
Do be sure to mark your calendars for February 25, just two weeks from today. That Tech-Talk will feature guest expert Alex Hills from Carnegie Mellon. Alex is an expert in the area of wireless networking and will talk about the technologies now supporting wireless implementations. Plan on joining the session and invite friends and colleagues. Have a party in your office!
HS: Invite us, if you're going to do that.
GM: Check the website for other upcoming spring events, and always, we welcome suggestions and feedback on what and whom you'd like to see here on Tech-Talk.
Thanks to all of you who helped make this possible today: the Board of CREN; our guest expert David Wasley; our technology anchor, Howard Strauss; our Web content producer, Terry Calhoun; to Brad Peck and Lee Perles of CREN for operational support; Paul Bennett at UM Web services for encoding; and to all of you for being here. You were here because it's time. 'Bye, David.
DW: 'Bye.
GM: 'Bye, Howard.
HS: 'Bye, Greg. Thank you, David.
GM: 'Bye, everybody.
