|
Topics covered include:
[Top of Page]
JB: Welcome to the CREN TechTalk series for spring of the new millennium and to this session on "Certificate Authorities on Campus." You are here because it's time to discuss the core technologies for your future campus.
This is Judith Boettcher, your CREN host for today, and I'd like to welcome our technology anchor for TechTalk, Howard Strauss of Princeton. Howard is a well-known web and emerging portal expert. Welcome, Howard.
HS: Thank you, Judith.
I'm Howard Strauss, the technology anchor for the TechTalk 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 ask those very important follow-up questions. You can ask our guest expert, Jeff Schiller, your own questions by sending e-mail to expert@cren.net at any time during this webcast. If we don't get to your questions during the webcast, we'll provide answers in the webcast archive.
The concept of a certificate is nothing new to any of us. Our birth is announced by the issuance of a birth certificate, and our demise is validated with a death certificate. In between, we buy gift certificates, stock certificates and certificates of deposit or CDs. All of these certificates proclaim to the world something about us or something about something we own.
Birth certificates establish one's identity, age, birthplace and so forth. They are issued by some authority that has been certified to issue them. A birth certificate is a fine way to establish one's identity if the issuing authority can be trusted, and if the certificate can be proven to be authentic. I can also take my birth certificate to the US State Department and, along with other information, use it to obtain a passport, which is really just another certificate. Having obtained a passport, I can use it to travel from country to country.
If I bring a CD to the bank that issued it, and if the CD has reached maturity, once the bank has established my identity, it will give me the cash value of the CD plus accrued interest. The bank will give me money because it is the trusted authority that issued the CD and it trusts itself. It has many safeguards to insure that the CD I present is real and was not just turned out on my laser printer minutes ago. Similarly, I can sell a stock certificate to a stockbroker, once I establish my identity and the authenticity of the stock certificate. The stockbroker insures that he can trust the issuer of the stock certificate before it hands over any money to me.
While there are many authorities that issue certificates, there is no supreme certificate authority. The State Department has lots of credibility at border crossings, but you can't use your passport as a gift certificate at Barnes & Noble. Although we tend to think of certificates as being pretty rectangles of official-looking paper, most CDs and stock certificates are just bits, stored in some computer, that are only turned into paper under duress.
Digital certificates are used in very similar ways on the Internet. They establish our identity and some other things about us and can be used for us to obtain access to various systems and data. But someone or something needs to issue those certificates, and the entity that issues them -- called the Certificate Authority, or CA -- needs to be trusted by the people who obtain the certificates and the people who accept them as proof of identity.
Digital certificates can also be used to encrypt information to maintain privacy.
Who are these certificate authorities? Why should we trust them? How do digital certificates differ from birth certificates, CDs or gift certificates? Why do we need these things anyway? And how do we get started doing this? Today, our guest, Jeff Schiller, will help us better understand these issues and others and help us answer some of the oldest philosophical questions, such as "Who are we?" and "Who do we trust?" Well, at least Jeff will tell us how to do that on the web on today's webcast of TechTalk.
Judith?
JB: Oh, thank you very much, Howard, and a great introduction to this -- just all different kinds of certificates, and also the fact that certificates often tell us not only who we are in one role, but often in many other roles as well. So I'm anxious -- and I'm sure our audience is, too -- to hear from Jeff and to talk with him about certificates today.
Our guest expert, as I mentioned, is Jeff Schiller. He is the Network Manager at the Massachusetts Institute of Technology and he has managed the MIT campus computer network since its beginning in 1984. He is the author of MIT's Kerberos authentication system and also a founding member of the Internet Privacy Coalition. There's much more about Jeff on the event page, so you can just traverse there. Jeff is also well-known to TechTalk participants, having been a guest expert here about a year and a half ago, also talking about -- guess what! -- certificate authorities and their role in the PKI infrastructure. So we're looking forward for a nice update today.
Welcome back, Jeff.
JS: Thank you, Judith. It's good to be back!
JB: All right, thanks so much.
Topics
HS: Okay, Jeff, one of the things -- I think I explained adequately to the listeners what a birth certificate is. I think I've really got that pinned down. Perhaps you could tell us what a digital certificate is.
JS: Okay. By the way, you left off one of those all-embracing important questions.
JB: Which one was that?
HS: Which one?
JS: "Where shall we have lunch?"
JB: Oh!
HS: I assume you're going to cover that? No, we probably won't.
JS: No, we won't.
JB: And "What time is it?" Did we skip time zones here?
JS: Now, now!
Anyhow, basically, when you work at computers -- I mean, we use birth certificates to identify ourselves to other people. We have a piece of paper, they understand how to read it, and of course they all know that my picture on my birth certificate is really me, right? Or is it that little bitty footprint? But leaving that aside, we have various credentials that we use in person-to-person context -- the most often people probably run into, of course, is their driver's license or their passport.
Well, computers, on the other hand, aren't at that stage of development. They don't quite yet have eyes, and when we sort of sit down in front of them, we can't sort of show it our driver's license and have it be able to recognize that's in fact a valid driver's license.
So instead, computers use basically encryption keys. As far as the computer is concerned, I am who I claim to be if I can demonstrate knowledge of a cryptographic key which only I would know. And in the case of certificates, we use a technology called Public Key Encryption which has the property that there really is this magic number -- this private key -- that only I know and I can demonstrate that I know that without revealing it.
So I don't actually have to tell you what it is to prove that I know it, but instead, I can do what's called a digital signature which is a way of demonstrating knowledge of this magic number, this key, without revealing it.
HS: Could you tell us how you get those keys? Where do they come from?
JS: Well, actually, with public key cryptography, there's actually two keys. There's the private key, which only I know, and then there's the public key, which everybody else knows (and in a second, I'll say how they know that), and using the public key, I can -- you use my public key and I use my private key and I can prove who I am to you.
Now, where that key comes from is at some point in time, I create both keys. I run a mathematical algorithm, or more to the point, I run some software that does that for me.
HS: You really mean you run it, or somebody gives it to you?
JS: No, I mean I run it! In the case of client certificates, it's typically your web browser that does it.
JB: But it's something that I as a user would go to a website and, through my browser, actually request this pair of keys?
JS: Ah! But the browser itself creates the keys, not the website.
HS: How does it make sure that it doesn't create the same one for you and for me?
JS: Ah! Well, that has to do with the laws of probability. Basically, the probability --
HS: That's the only thing that's saving us is chance?
JS: Yeah, basically. Well, you know, as I tell people, all the air in the room that I'm in could suddenly decide it wants to be in one corner, leaving me gasping in a vacuum. But that doesn't tend to happen very often, so we don't worry about it.
JB: I'm glad it doesn't! Jeff, it might be helpful for our folks who are listening in, if they scroll down to about the middle part of the event page. There's a place that says, "Here's a digital certificate that contains CREN's public key." And if people take a look at that, you know, it demonstrates the different parts to a certificate that actually holds a public key. Would that be useful right now?
JS: Yeah, but let me just say something. And people certainly should go look at that right now and get ready to look at that. But let me sort of say a little bit more, and that is, with this key pair -- public and private -- I can use my private key to digitally sign a document. And that document obviously is a digital document. Then you, using my public key, can verify that I, in fact, signed that digital document.
Now, what the certificate is, the certificate is itself a digital document that basically associates my public key and my name -- because you can use my public key to verify something I've signed, but you need to know, how do you know that's really my public key? And of course, the answer is you have a digital document called a certificate that says "This public key, which is a pile of bits, belongs to Jeff Schiller," and that's signed by the public key of a certifying authority.
And that certifying authority has its key also stored in a certificate, and that certificate is issued by yet potentially another certifying authority. Now obviously, at some point we can't just have one key signing another key signing another key, ad infinitum. We have to get to a -- we've got to stop this process.
Topics
HS: So there's kind of a hierarchy of trust here?
JS: There's a hierarchy of trust, and we call the certifying authorities at the top "root certifying authorities." And a root certifying authority, as a matter of convention, will create a self-signed certificate. In essence, it issues itself a certificate, signed with its own key, which means that you have to be careful about making sure you have the right public key of a root CA.
HS: Who are some of these root CA's?
JS: Well, if you use a browser, you see root CA's are issued by companies. For example, Verisign has a root CA. There's another company called Thought Consulting has a root CA. The US Post Office has a root CA, as does Canada Post.
And most of these are built into your browser. So how do you get the key to these root CAs and get their certificates? The answer is, when you downloaded your browser or you bought your computer, they sort of came with it.
HS: Is there some way to look at my browser and see which ones are there?
JS: Yes, there is, and it depends on which browser you have. I can tell you off the top of my head that with Netscape Version 4, you click on the Security button that's on the top of your screen, and that shows you a menu of security items, and one of them is Certificates. And there's a couple of buttons there. One says Your Certificate, one says Websites and one says Signing or CAs, and you click on that and it will show you a list.
JB: I think in the Netscape browser version I've got now, it's under the Tools menu, and it asks under Security Information. And you can, in fact, see the list of probably about 40 different signers that are contained in that browser already.
HS: Okay, so just going on with this thing, we somehow get -- again, there's these root authorities and underneath them is what?
JS: Basically, you have root authorities and for different types of certificates, different things may be under them. But in general, for client certificates, what you will find is under the root authority would be an organizational authority, typically belonging to a school or to a company. And that certificate is signed by a root authority and under an organization's authority, you may find sub-organizations like various departments or you may find users directly. And that's up to how an organization structures itself.
JB: Well, in the CREN digital certificate that people can in fact click to, that is a good example of a root certificate in that the issuer is listed as CREN and then also the subject in the Subject field is also CREN, right?
JS: That's right, that's because it's signing itself.
JB: Right, okay, and that's the way to get started. When I'm on a campus, for example, and at your institution, for example, Jeff -- at MIT -- has MIT also signed a root key for MIT?
JS: Yes, but we decided to actually use public key encryption -- PKI is the term we use, Public Key Infrastructure -- about two years ago. And at that time, we created a root CA for MIT. We actually created two of them. They're used for different things. And we started issuing certificates underneath those, about, I guess, two years ago.
JB: Okay, and is there any particular reason why you did create two of them? Do you want to go into that right now?
JS: Well, let me just simply say that when we talk about using certificates, particularly in the context of the World Wide Web, there's really two kinds.
There's kinds that are used to prove who a server is to a user. So for example, if I go to the MIT Registrar's website, I want to know I'm going to the real Registrar's website, not some bogus one run by a student who's trying to fool me.
And the other kind is what we call a client certificate which is how you prove to the website that you are who you claim to be. So before the Registrar's website will give you your grades, you have to prove that you are you and not your roommate.
JB: I think that's a really good distinction and one that I was confused about for a long time, Jeff, and that is that as a user -- as a client -- I have a digital certificate issued to me. But then when I set up a secure server environment, the secure server also has a certificate that has been issued to that server.
HS: Are there any other entities other than people and servers that get certificates?
JS: Well, in general, we use a certificate to prove identity, and typically in the case of the web, the identities we're worrying about are servers and humans.
But in a business-to-business situation, for example, using Electronic Data Interchange -- EDI -- we might have certificates issued to both ends of an EDI link that's used to prove transactions going down the link are from the appropriate parties. So the simple version is they use certificates to prove what something is and exactly what that something may be is dependent pretty much on the application context.
Topics
HS: You said that you have your own local certificate authority at MIT. Is that correct?
JS: That's correct.
HS: But does that mean that there had to be some higher level certificate authority that allows you to do that?
JS: No.
HS: Do you just go off and become a certificate authority if you feel like doing?
JS: Yeah, I mean, we created a self-signed certificate and now the trick is, because we're just MIT and we're not Verisign and we don't have any special deals with Microsoft and Netscape, our root certificates are not built into the browsers. So at MIT, people either have to manually install that certificate -- and we provide instructions for how to do that -- or they have to get an MIT distribution of the browser that has that built in. So that's one of the headaches that we have to put up with is that we have to get our root certificate manually disseminated.
HS: If I received a certificate from MIT out here at Princeton, where I have not modified my browser, what would I see? How would that look to me?
JS: Well, interestingly enough, if you got a personal client certificate, your browser doesn't need to know our root CA because you're going to prove yourself to our servers and our servers would need to have the root CA.
But for example, if you were to go to one of the websites -- secure websites at MIT that's secured with a server certificate we issued -- your browser would basically put up a dialogue box and it would say, "Gee, you've gone to a secure site that uses encryption, but we don't recognize the certifying authority that issued its certificate. Would you like to continue?" Okay?
HS: Would it tell me this certifying authority is MIT?
JS: It would tell you the name of the certifying authority, but without having its root certificate, it wouldn't be able to tell you much about it.
HS: So basically, I would look at the name and say, "Do I trust anybody called MIT?"
JS: Yeah, although I'll tell you, anybody could do that because you don't have a valid root CA. You know, somebody at some completely evil.org could claim to be MIT, so you can't really trust that information.
HS: Okay, what would it take to trust that MIT thing? I mean, if a certificate comes in, what would it take for me to trust it? How would I ever know it really is MIT? Would you have to have something done at a higher level? Would you have to have a higher level certificate authority that I did trust vouch for you? How does that work?
JS: Well, ultimately in all of these technologies, there's an initial what I call the "leap of faith." Which is that, when you get your first root CA or you get the root CAs that they've not been modified in transit.
Now, for most people, that's when they download their browser. The leap of faith that they're taking is that somebody didn't interfere with the FTP session. (And oh, by the way, there's technology to interfere with FTP sessions. This has been demonstrated.) But what we're hoping is that when you download your browser, at that moment there were no bad guys.
Now, quite frankly, if somebody did interfere with the download and substituted one of the certificates, you'd probably know pretty soon because when you went to a legitimate site, it would claim to be illegitimate. And you'd say, "Well, this doesn't make sense!" And eventually, you might re-install.
HS: So in the browser is all the public keys of these root CAs.
JS: That's right. Now, in the case of MIT, you have to actually download our root CA from a particular website, and the leap of faith you would be taking is that when you're downloading that particular certificate, that in fact, you're getting the right one.
Topics
HS: I'm just trying to understand the relationship between the lower level CA's and these root CA's. Are they related?
JS: Well, every certificate actually contains not only the name of who it belongs to and their key, but also the name of the authority that issued it. So if presented with a certificate, you can actually see, oh, this was issued by this other organization and you have to get their certificate to then determine whether or not that one is valid. So it's an iterative process as you walk up the tree until you get to the root.
HS: And do you have the same certificate authority issue client side certificates and server side certificates, or do you have different CAs issue them?
JS: We actually use two CAs and I don't know if we have time today to go into the technical details of why that's the case. But the simple answer is that the security properties that we have to ascribe to those two CAs is sufficiently different. The risk of compromise is actually different for the two CAs so by having two of them, we get to separate that risk out.
Topics
HS: Okay. We have a couple questions. I think we've gone far enough into this so that I think we actually can approach them. We have one from Eric Norman at the University of Wisconsin, and Eric says, "I've heard people say that you should revoke certificates when someone's affiliation with the organization is terminated," and he says, "Does that mean you should revoke a student's certificate when they graduate?"
JS: Well, you know, this whole notion of revocation is very confused and complicated.
HS: Excuse me, maybe we should mention one thing which I think we've left out here, and that is that when we issue a certificate, it has a validity period on it. Is that right?
JS: That's correct.
HS: So it'll expire itself.
JS: That's right. In fact, we tend to make our student certificates expire towards the end of the term.
HS: So you kind of issue them just for one year.
JS: That's right. We tend to issue them for one year and then they have to get a new one.
HS: And for faculty and staff, you issue them for how long?
JS: Same thing, for one year.
HS: And so you have to keep renewing them every year?
JS: That's right, you have to keep renewing them, which is not difficult. It involves going to a website and clicking some buttons.
JB: And do you have them all expire somewhat close to the same time?
JS: Yeah, we tend to. I'm not sure that's a feature, but that's how we're doing it at the moment.
JB: Okay. So that may be something that we may want to refine in the future then. Back to the question.
HS: Back to Eric's question, yeah, so you're saying the certificate expires when the student graduates anyway?
JS: Right, but it turns out, even if we ignore that issue for a moment, what's the harm done? I mean, for example, in our case the certificates are used to prove to sites at MIT that the person is who they claim to be and guess what? They still are who they claim to be.
JB: They're still that individual, in other words.
JS: They're still that individual, and if the Registrar wants to make information such as transcript data available to students who have already graduated for a period of time, why not?
JB: I think part of --
HS: But I think Eric's saying, how do you know who they are if they no longer have a certificate?
JS: What I'm saying, they still have their certificate.
HS: But if --
JS: Well, I mean, if it's expired, that's a different matter. But what I'm saying is, it turns out as an aside at MIT, using your Kerberos password is how you get your certificate, and we don't turn those off when people graduate. We give them a grace period of about six months and in fact, we are even discussing changing that to be forever, so --
JB: All right, so that if I am an MIT student and I have an MIT certificate, I could continue using that at least for a period of time as you now have it structured.
JS: That's correct.
HS: But if the thing did expire? I mean, I'm just trying to understand this. If this thing did expire, then this hypothetical student that Eric's talking about couldn't come in.
JS: If we made that decision that we weren't going to let them get a new certificate, yes.
HS: Okay. So you can't get rid of these things. It seems clear, you can't get rid of these things if people still need access to the system.
JB: Well, and I think one other question, though, one other reason why someone would ask this particular question is that for example, if one's certificate is being used to access licensed materials that are licensed for current students rather than graduated students, that there might be some difficulty in students continuing to use that particular digital certificate if it's being used for that particular authorization, right?
JS: Well, see, now there you're getting into authorization, which I believe is actually a separate thing. I think that before you grant access to resources, you have to ask two different questions. One is, "Is this person who I think they are?" -- i.e., does their certificate say they are who they claim to be? And then the second question is, "Given that I know who they are, is this person allowed access to this resource?" And I think it's at that point that you say, okay, this person's not a student anymore, so we won't grant them access to this resource because the license says they can't have it.
But I personally don't view the certificate as the thing that should be granting that authorization. But instead, that's very dynamic data, what you may have access to. For example, you may have a situation where a student only has access to certain information if they're taking a certain class. Because maybe you're dealing with software and you have only 20 licenses and there's ten people in the class and you don't want people who took it last semester to have access. And, you know, yet the certificate that they get that says who they are might be good for an entire year and it's an institutional-issued object as opposed to a per-class thing. So again, a database of who's in the class that's consulted by the resource, it makes a lot more sense.
HS: Okay, I think that actually kind of leads us to this question from Christopher Werner at the Robert Bosch Corporation, and -- at least, I think this is Christopher Werner!
JB: Well, it looks like it may be Karen. We don't know.
Topics
HS: Might be Karen. It's signed "Christopher." Actually, if you want an interesting problem with certificates here, we have an e-mail message with two identities. Chris or Karen, whichever you are, Chris or Karen says, "Most business transactions require three things to validate them. Who, what and where? A PKI does a good job of providing digital certificates to support transaction authentication -- the "who" portion. What mechanisms do you envision providing the "what" and "where" of transaction validation and how would these mechanisms be used to validate denial of transaction occurrence?"
JS: Well, again, if we look at -- I mean, the PKI tells you who. Presumably, you know what they're trying to get at because they're making a request to get at a certain thing. And as far as "when" is concerned, well, you know what time it is. And where they are, that's a dicier issue because actually knowing where somebody is located on the Internet can be very, very difficult. I certainly know this because I run a website that tries to only distribute software within the United States, and just answering the question, "Is this web request coming from inside the United States or outside the United States?" is a difficult problem to solve.
And there's numerous techniques that make it difficult. For example, if my IP address being at Net 18 indicates that I'm at MIT. But I might be on the Stanford campus and dialed over the telephone line and using an IP address that belongs to MIT because I'm dialed into MIT's network, but physically, I'm at Stanford. So what does that mean? Well, maybe I don't care. Maybe if I'm dialed into MIT, I'm logically at MIT. And that's not really a problem that we can solve with certificates, and in fact, it's a problem that the Internet in general just doesn't have a good answer to.
Topics
HS: Okay, since we're talking about certificate authorities, and this is a CREN broadcast, we'd be remiss if we didn't talk about the fact that CREN has become a certificate authority. But are they a root certificate authority or how do they fit into this whole scheme? And why is it a good thing to have these folks out here?
JS: Okay. Well, I mean, if you look at the problem we have here at MIT, we've set up our own CA and we're issuing credentials to our own students and we use it for our own purposes. In fact, every student at MIT, in order to register for classes, has to have a certificate because they authenticate themselves to an online system run by the registrar which they must use, with the exception of certain special cases.
But the catch is, that's great as long as you're staying within the MIT campus, but now, what if I wanted to offer services like, say, library access to, say, students at another university? Very often, there will be joint agreements between universities to share certain resources. Well, what if we have a service provider that wants to provide access to a whole range of universities? Well, today, without the CREN service what would have to happen is, if I wanted to accept students, say, from Harvard University, I would have to install on my servers the Harvard root CA and then the Princeton root CA and actually, I'll wind up with I don't know how many root CAs that I have to know about and if any of them change, I have to be updated. Or if things stop working as far as students at that institution trying to get to our resources.
So what CREN has done is by establishing a root CA for higher education, we can wind up getting our certificates signed by CREN. In fact, I've taken the MIT root CA and, in fact, have created another certificate which has the same key and in fact it has the same name, but instead of being issued by itself, it's issued by CREN. And now, if somebody trusts the CREN root CA, then they can validate people coming from MIT and multiple institutions certified under the CREN CA. Then you can configure your service with but one root CA, namely the CREN root CA, and yet be able to accept credentials from any other institution that's been similarly registered.
HS: Is what's really going on that a CREN CA is assuring you that it trusts that the MIT CA is really the MIT CA and the Princeton CA is really the Princeton CA? Or is it going down even lower than that?
JS: No, it's doing the former. It's just saying that this certificate was issued by MIT. It's up to MIT to figure out what MIT's policies are.
HS: So you sort of really want to trust -- I mean, when you trust CREN at that point, what you're trusting is that CREN has said, "This really does come from MIT." So you can really believe that. And then if you trust MIT, you're okay.
JS: That's exactly right.
Topics
JB: Maybe we want to talk at this point, Jeff, about the three major phases of setting up a certificate authority on campus, since that's where kind of the rubber hits the road. When we were talking about this during our prep session, we kind of looked at three major phases. Number one, the identity phase, and then number two, the actual setting up of the certificate authority. Do you want to talk just a little bit about just what are the components of a campus CA? I think we've talked about it a little bit in terms of first issuing -- you know, there's the setting up of both the hardware and software that allows one to issue these types of certs. Do you want to maybe just describe a little bit of what's involved with that?
JS: Well, first off, let me say a little bit about what we do at MIT, but I'm not going to go into MIT specific-specifics, if that makes sense. Basically, individuals obtain their certificates from a website, so this is actually not a hugely difficult process. It's a very much point-and-click process. They go to a website. In our case, we're leveraging Kerberos so they enter their Kerberos name and password, they enter their MIT ID. They're then presented with a page where they generate their certificate, and that's like all automated. And you know, a few more mouse clicks and they have their certificate.
HS: Judith was talking about three phases.
JS: I understand. Let me go on. That's what happens --
HS: I just wondered what phase we're in here.
JB: We kind of skipped phase one and just kind of focused on phase two, Howard.
JS: I'm trying to explain what the user's perception is.
HS: Okay, that's fine.
JS: What they actually see. Now, how we get there is, like I say, we've leveraged off of Kerberos. Another institution that does not have an already in place global authentication system, interesting problem. How would you go from you don't have any authentication system that's global -- meaning that you can use throughout the entire institution -- how do you get yourself into the certificate business?
Well, there's a couple of interesting ways to do it. One thing you probably already have is, phase one, you probably know who your people are. You probably have a directory that says that John Doe has got e-mail address jdoe@institution.org and is in room 7-17 or something. That's important because if you know where people are, you can now leverage yourself the rest of the way. For example, one technique you can use -- and this depends on you believing that your e-mail system is reasonably secure -- is you can have people go to your certificate server and have software on your certificate server asking for their e-mail address. And on the basis of their e-mail address, do a look-up in the directory -- and how you do that's up to you -- and get their full name, and from that, construct the name that would appear on their certificate.
If you look at the CREN CA page, you'll see that names actually have some structure to them. Once you know what the name that they're going to have, what you can then do is rather than download the certificate right then and there, instead you can e-mail them, in essence, a password which they can then use to come back to the certificate server to prove who they are. And in that way, what you've been able to prove is that the person obtaining that certificate can at least read e-mail sent to that e-mail address.
Now, if you're concerned that that's not strong enough, if you worried that other people might be reading other people's e-mail and could use it to take advantage, another thing you can do is you can establish a one-time password for each person and you can literally mail them in the campus mail a password that's just for them that you have recorded in the database. And then, in order to get their certificate, not only do you e-mail them a password, but you also require them to enter that password they received in the campus paper mail. And so now in order to subvert the system, someone would have to intercept e-mail and paper mail, which starts becoming a difficult thing. At some point, you can go to the driver's license authority with a piece of paper claims to be a birth certificate. You know, you're making it arbitrarily hard.
Now, what we actually do at MIT is we have a two step process because we are still using Kerberos as well as certificates and so we do the paper mail step with Kerberos, meaning you have to have this special password that's mailed to you in order to get your Kerberos account. And what we do with students is part of their registration material, when they show up physically on campus to get their ID picture taken, we hand them a packet of stuff and we actually call it the Account Coupon. We put little frilly writing on it and we sort of jazz it up. And also, by the way, we include the rules of use on it so they sort of can't use the excuse when they get their account, "Oh, I never knew there were rules and I never knew what the rules of use were," because it's kind of sitting right there.
JB: Um-hum.
JS: And we also make them click through the rules of use as well.
JB: So actually, that would be equivalent to how you really register the students, as part of that registration process.
JS: Um-hum.
JB: Okay, all right. I'm sorry, did I interrupt you in the middle of things?
JS: No.
JB: Okay, we have another question coming in. Howard, would you like to --
Topics
HS: Sure. This is from Michael Geddes who's -- actually Michael has become probably as good a question answerer as I've been an anchor. He's pretty regularly out here and since Michael was from Princeton -- now he's at Georgetown -- I guess I'll do his question here. But Michael says, "What does Jeff think of the Federal Bridge CA model vs. the traditional root CA model?" And Michael asks you to apply your opinion to the role of the CREN CA. I've never heard of a Federal Bridge CA.
JS: It's hard to explain what the difference is because it's sort of very subtle. Traditionally, when we have a root CA, the root CA usually establishes a policy that governs how inferior CA's operate. And to be honest with you, that type of let's enforce policy through the PKI hierarchy only works within an institution where there can be common policy. When we've tried in the Internet community, when we try to have a root CA that says, "We'll dictate what policies institutions have," that never works.
Let me give you an example. For example, I just explained with phase three how you might authenticate who your people are before you give them a certificate. Well, another institution might have a rule that says, "We're a small institution and so we're not going to give anybody a certificate until they appear in person with a picture ID and show it to a special security officer. And so therefore, we really know who these people are." But they may have 100 people, so they can afford to do that. Well, a root CA might say, "We want to be real secure so we're going to require everybody underneath us to do that." Well, guess what? We at MIT can't do that. We have too many people and I doubt the University of Michigan could do that. They have even more people. And so that policy isn't always appropriate.
Now, when you do these bridge CA schemes, in essence what that is, you're basically saying, "We're not setting up a root. We're not in essence propagating policy. What we're merely saying is that we're introducing different CA's to each other." And that is pretty much what CREN is doing in that it is basically saying to Princeton, "This is MIT." And similarly to MIT, "This is Princeton." But it's still up to the individual organizations to set up their own policies.
Now, I believe the Federal PKI Bridge stuff also is a little bit more formal than what CREN has been doing inasmuch as they actually required a published policy so that if I get a certificate from a different CA than my own through the bridge, then I should be able to a repository and obtain what the policy that CA in fact used before it issued credentials, so I could know whether or not I want to believe that that's an acceptable solution, an acceptable certificate.
HS: What's the status of the CREN CA? For example, I don't see it listed on my browser as a root CA.
JS: Well, it's not built into the browsers at this point.
HS: Is it going to be at some time?
JS: That depends on negotiation. See, the browser vendors control who appears there and that's up to them in terms of what terms and conditions they would -- I mean, it would be great if we could get a CREN certificate installed in the major browsers, but that's something that they control and we have to negotiate for.
JB: It will, in fact, facilitate deployment. You mentioned before, Jeff, that there's two ways that the students at MIT get the MIT certificate in their browsers and one is by downloading a version of the browser that you have on your site, and the other one is you step them through that, then?
JS: That's right.
JB: You also had mentioned before on this browser question that does come up -- oh, by the way, just let me invite those that are listening to go ahead and send in their questions. Now is a really good time to do that.
Topics
But coming back to the browser question, is the fact that since we started talking before about client certificates and server certificates, when is it really important to have the browser recognize the certificates?
JS: It turns out it's very important to have the root CA built into the browser for server certificates because in this case, the server is trying to prove who it is and it's proving it to you and of course, you're operating the browser.
Now, in the case of the CREN CA today, we've really been focusing on client certificates, giving them out to people at institutions so that they can access remote resources. And in that case, the only people who really need to have that root CA certificate are the operators of servers. So if I operate a web server that grants access, say, to library publications and I would like to grant that access to selected CREN members or people who have certificates signed by CREN, then I -- sorry about that, I just got disturbed here for a second. Then I have to install, as the server operator, the CREN root CA, but all my users don't have to have that.
Now, if CREN was to start issuing server certificates, then the browsers -- that would be critically important for the browsers to have that root CA built in to avoid people having to answer a lot of dialogue boxes.
JB: But if CREN starts working with and having the folks at JStore be one of the partners with CREN, having the server at JStore have the CREN certificate will serve many needs.
JS: That's a sufficient condition to get going.
Topics
HS: Okay, in a sort of related area, we talked about using certificates for signing e-mail, but I understand that people also use certificates for encrypting e-mail. How's that different?
JS: Ah! We today at MIT use certificates for web-based authentication. And it turns out, I recommend people do that. I think the technology is there and it's ready to go.
On the other hand, using certificates for encrypting e-mail to others is a bit of a trickier problem, and the reason it's trickier is it turns out for digital signatures -- for authentication -- you can have many certificates. If I've got three computers -- I've got a laptop, I've got a computer at home, a computer at the office. Now, there is technology such that I can get a single certificate exported into a file and then install it on those other machines. But I'll be honest with you, that technology is not easy to do. It's an obscure process and most people have trouble completing it.
HS: I thought that some people just carried the thing around on a diskette. You could do that.
JS: You can try! But it's tricky. I mean, exporting a certificate and then being able to re-import it again, particularly if you have different versions of the browsers in different places, is not guaranteed to be easy to do, let me put it that way.
HS: Okay.
JS: Now, we solved this problem at MIT by saying, "Hey, just get three certificates!" The fact that they'll have different keys doesn't matter because all three certificates have your name and prove it's you. Now, what happens --
HS: That's because when you send e-mail, the public key goes along with it?
JS: That's correct. If you were to use it in an e-mail signing context, the certificate with the public key is sent with it.
Now, similarly, if you forget -- now, one of the things we didn't mention is your private key will be a very long number. You're not going to memorize it. So that tends to be stored in your computer in a file and that file is encrypted with a password and browsers will ask you for that password when you go to use it.
HS: But when you say it's a really long number, how long is it?
JS: Well, that kind of depends. A 1,024 bit RSA key would be 128 bytes.
HS: Okay.
JB: It's more than seven numbers!
JS: No kidding!
JB: Or more than ten or 12.
HS: Like where our memory kind of gently falls off.
Topics
JB: Yeah. You know, before we -- the time here goes so quickly, I really like to have us talk a little bit about the application, Jeff, that you've got running at MIT where you're using these digital certificates for students when they go through the registration process. Can you tell us a little bit about how that works and how it is working?
JS: Well, it's actually been working very well for us. I mean, in order to register for classes, students go to a web page run by the Registrar. They can select their course schedule. It actually will build, much as a web commerce site builds a shopping cart, we build a schedule. And when they're ready, they basically authenticate using their certificate and we definitely know it's them and that stores their course selection.
Similarly, they can go and read their transcript and they can actually update their mailing address and other information. And we have found that to be very effective.
JB: And I think you did give us permission. We've got the actual registration site up on the event page today so folks can go and take a look at that.
JS: Yeah, you can go and build schedules. You can't quite register for classes, but you can actually go and build the schedules, look at the online course catalog and what-have-you . But like I said, the final part of that process is the registration with the certificate. Similarly, on the staff side of the house, the open enrollment period when we select our health coverage and FRAP accounts and all that kind of stuff, that's also mediated by certificates issued by employees from the same server.
And that's been working pretty well. We deploy that along with a telephone call-in mechanism and we've shortened our open enrollment period from one month to two weeks because it was more than enough time for people to do it. And it also, the old paper based mechanism allowed you to basically specify your preferences exactly once and if you wanted to change them after you sent in the form, you had to go get another blank form and go do it. And with the web based mechanism, you can go in and throughout that two week period, go and diddle things until you're satisfied with it.
Topics
JB: Okay, listen, we have another question that's coming in that links to a question, one of the 31 questions that we haven't gotten to, Jeff, and that concerns if I'm an individual on the MIT campus, how many certificates am I likely to have?
We've got a question from Frank Peters here from Mississippi State University and he asks the following question. "Suppose I have multiple certificates, one from MIT, one from CREN, one from Verisign. Suppose I connect to a server that accepts certificates from MIT but not CREN. How does the client know which of the three certificates will be accepted by the server? And is there a protocol for exchanging information about acceptable root authorities?" Too many questions there!
JS: Okay, the answer is it's built into FSL3 and Netscape. If you select the feature called Let Netscape Decide Which Certificate to Use, then the web server, when you contact the web server, it will say which CA it wants to see a certificate from and the browser will provide the correct certificate.
JB: That sounds like it's working very well.
JS: Yeah, and to answer the first question in that list, in general at MIT, we expect -- today people in general only have one certificate, the MIT certificate.
JB: Okay, and that tells people who I am and that I am from MIT, basically.
JS: That's correct.
JB: Okay. Howard?
HS: Sure, there's a thread that I think is still left hanging here. It has to do with multiple certificates, and that is that, Jeff, you were talking earlier about using certificates for encryption and I think you were about to say why multiple certificates weren't a good idea if you were using them for encryption.
JS: Ah! The problem we have with encryption is if I want to send you encrypted mail, I have to know your one and only public key, which means you have to --
HS: Why do you have to know my one and only public key?
JS: Which means you have to have but one published certificate which I can find, and then you get into issues with key recovery because if you lose -- today with a signature certificate, if you lose the key, it's no problem. You create a new key and a new certificate and away you go. But if you have received encrypted mail and you've lost they key, basically, you've lost that mail. So if you were to use this for serious business transactions, you have to come up with some scheme for basically recovering lost keys because people forget passwords and hard drives do fail.
JB: Um-hum
JS: That's a tougher problem.
JB: Howard, we have another question from another person at Princeton, would you like to -- and it's actually a multiple part one.
HS: This is a question from Donna Tatrow and, as Judith mentioned, she's from Princeton. She was formerly from Cornell, if folks are keeping track of where these people are from.
JB: Oh, I didn't know that!
Topics
HS: We've got a lot of people from Cornell down here. Might be the warmer weather. Donna says, "Could you talk a little bit about the types of certificates that you are issuing at MIT? Do you issue anonymous certificates? Do you issue certificates of different strengths? Do you issue session based certificates, very short lived certificates for signing only? And does MIT provide key escrow?"
JB: And if you've forgotten any of those, we can read them back!
JS: Okay. We only issue -- we do not issue anonymous certificates.
HS: What are anonymous certificates?
JS: We have not issued anonymous certificates.
HS: What are they?
JS: An anonymous certificate would be a certificate that, instead of having your name, had some identifier that's not directly traceable back to your name. They're a big issue in the library community because there's some concerns -- and they're completely valid concerns -- that you don't want to have a situation where in order to look at a certain article, you have to give your full name lest somebody then use that to record who's looking at what reading material, which is a big no-no in the library community. We've not solved that problem. We're looking at the problem, but today, we do not issue anonymous certificates.
We also do not issue certificates of multiple strength. We recommend people get --
HS: What's that mean?
JS: Hm?
HS: What's that mean, certificates of multiple strengths?
JS: Typically, it means different key lengths and you know, frankly, there's a period of time where that was a concern because shorter keys are less secure but also computationally faster. But with most modern computers, you can use effectively unbreakable keys and it's fast enough.
HS: Yeah, there aren't too many 486s around any more.
JS: Right. Even a 486 can manage a 1,024 bit key without too much trouble.
JB: And most keys are of that length?
JS: That's right. In fact, I recommend that as a minimum at this point. So basically, we recommend use the strongest key length you can and by default, we don't give out -- well, when somebody goes to the certificate server, they can choose how long they want their certificate to last. The upper limit is one year, though occasionally we declare certain fixed points, in this case July 31. No certificate we're issuing today will expire after July 31. We're about to change that, but that's how it is today.
But if you want to have a one-day certificate, you can get a one-day certificate. In fact, we have a hack. If you ask for a zero day certificate, you get a one hour certificate, and we have people who do that. That's particularly interesting if you're using a friend's computer, you need a certificate but you are concerned you won't be able to properly delete it. So you just get a very short lived one. That's user option.
HS: Then she said certificates for signing only?
JS: Well, we can't restrict them. If people want to use those certificates for encryption and they know what they're doing, it will work.
HS: And what about key escrow, which is her last point? Do you do it?
JS: We don't implement key escrow. No.
HS: Why not?
JS: Well, frankly, we don't support encryption as something people do on their own. We're doing it for authentication and for authentication, you know, you don't need --
HS: Do you think it's a bad idea?
JS: Well, you know, unfortunately, I think the technology's not evolved properly or to the right point because right now. If you get a certificate using a browser, you get one key that's used for both encryption and signing. And although you absolutely need to back up a key for encryption, the last thing you want to do is institutional escrow of signing keys because then you lose the ability to say only this person -- if John Doe has a certificate and John Doe signs a document, you say John Doe had to sign this. But as soon as the institution has a copy of the key, the answer is, well, John Doe could have signed it or the institution may have done it. And as soon as you enter that doubt, the ability to use digital signatures for potentially legally binding transactions becomes a little murky. So if an institution wants to do key escrow, it has to really only do it with encryption keys and if they keys are shared like they are today, it's fairly problematical.
HS: Okay, we're pretty much out of time here.
JB: I think we are.
HS: Into overtime.
JB: Yes, and at this point I generally see and ask, Howard, if you have any other final question that you'd like to ask Jeff before we kind of wrap up for the day.
Topics
HS: Jeff, if you could just -- I know we sort of touched on this a little bit before, but you're a university right now, let's suppose, and you really haven't gotten involved in the thing too much. How do you get started? How do you get into this digital certificate business?
JS: Boy, I wish that was an easy answer!
JB: You need more than two minutes?
JS: Well, I think the short answer is if you understand the technology, I mean, there are products you can buy. I believe Netscape and Microsoft both sell certificate servers. I can't comment as to how well they work because I did a roll-your-own. I do have some software, it's written as a Java servlet and we have it operating today under Java Apache. And although we have not put up public distribution of it for export issues (and frankly, I haven't had a chance to really package it for distribution), I do make it available at least in the United States to other institutions that are interested in setting one up. So one answer is to probably contact me and I can see about making my code available.
JB: Okay, but the other thing is perhaps to watch and see how the technology evolves with the commercial products?
JS: Yeah, and to, of course -- unfortunately, I don't have off the top of my head a reference to a good tutorial on PKI, but it helps to sort of learn how this technology works as a good first step.
JB: Okay, well, with that, I think we do have the event page for today's session that does have quite a nice set of resources that will give people an opportunity to research the area a little bit more before getting started.
Any other comment that you'd like to leave with the participants before kind of signing off here, Jeff?
JS: I think we've covered a lot of ground.
JB: Yeah, we only have -- not 41 questions, but perhaps about half of them. We had some really good questions and we thank the folks who sent those in.
For now, I'd like to just thank everyone who participated here today and be sure to set aside time in your calendars in just two weeks from today when we're going to have a topic on "Setting Up E-Commerce on Campus." Our guest expert on April 27th will be Jack Duwe from the University of Wisconsin and he has set one up there and is doing some really good stuff.
So many thanks to everyone who does support these TechTalks and we invite you and your institution to continue supporting them. Thanks to everyone who helped make this event possible today: to our guest expert, Jeff Schiller; to our technology anchor, Howard Strauss; to Terry Calhoun, event page producer; to David Smith and Patty Gaul of CREN; to Julia O'Brien, Jason Russell, Gayle Terkeurst and the whole support team at the MERIT Network; to Susie Berneis, audio file transcriber; to Laurel Erickson, transcript editor and indexer, and finally, a thanks to all of you for being here. You were here because it's time.
Bye, Jeff, bye, Howard. See you next time
HS: Bye, Judith. Bye, Jeff, this has been great.
JS: Bye-bye.
JB: Great, bye-bye now.
Topics
|
