Carl Malamud: Internet Talk Radio, flame of the Internet. We’re talk­ing to Cliff Neuman, who’s a mem­ber of the research fac­ul­ty at the University of Southern California. He’s also one of the prin­ci­pal design­ers of Kerberos, and the design­er of Prospero, which is one of the new breed of resource dis­cov­ery pro­to­cols. Welcome to Geek of the Week, Cliff.

Clifford Neuman: Hi. Thank you, Carl.

Malamud: Why don’t we start with what Prospero is. What is this nifty service?

Neuman: Well, one of the typ­i­cal answers that I give to what is Prospero is, what do you want it to be? And one of the rea­sons for that is that I see Prospero as fill­ing a num­ber of roles. Prospero is pri­mar­i­ly a direc­to­ry ser­vice. But in fact I see it as a direc­to­ry ser­vice that can be used to tie togeth­er the var­i­ous com­po­nents of a dis­trib­uted system. 

Malamud: But what do I see then, as a user? Do I see— Do I type ​“ls” and get a bunch of file names back? Is this a replace­ment for the ls command?

Neuman: Well in fact there is a com­mand called vls which you can type which will show you a bunch of files, in par­tic­u­lar those files in a vir­tu­al direc­to­ry that is part of a vir­tu­al file sys­tem that is part of a vir­tu­al sys­tem. Let me say a lit­tle bit about what sort of…the over­all idea which is behind Prospero. And that is a con­cept I call the vir­tu­al sys­tem model. 

Basically, we’re start­ing to see lots and lots of and lots of infor­ma­tion, and lots and lots of ser­vices that are avail­able over the Internet. And one of the things that over the past year, or over the past few years, peo­ple have start­ed to try to do is to try to come up with a sys­tem that can—so that users can think of every­thing that is out there as a sin­gle sys­tem. Unfortunately there are some prob­lems with this. In par­tic­u­lar when all of this is part of a sin­gle sys­tem, the sys­tem is just too big for users to think about. 

Malamud: It’s like hav­ing a direc­to­ry with whole bunch of files in it. [crosstalk] Is that the problem?

Neuman: Yes. That’s cor­rect. In fact the anec­dote I like to give about this is sup­pose every­thing were a sin­gle sys­tem and you sit down and you want­ed to see who is logged in and you type ​“fin­ger.” Well, you’d sit there for three days as the name of every user in the world that’s cur­rent­ly logged in typed out on your screen. So to address this prob­lem, I believe that the cor­rect approach is to allow users to select those resources and those parts of the sys­tem that are of inter­est, and then to treat those resources that they’ve select­ed as if it was a sin­gle sys­tem. So now, to an indi­vid­ual user, the user sees a sin­gle sys­tem which is much small­er than every­thing out there but is very much cus­tomized to what their par­tic­u­lar needs are. Whereas in the sys­tem as a whole, you’ve got dif­fer­ent views of this. So dif­fer­ent users see dif­fer­ent things. And there are a lot of prob­lems that come up when you do this. And some of the mech­a­nisms that Prospero pro­vides are designed to help you resolve the prob­lems that come up from dif­fer­ent users see­ing dif­fer­ent things.

Malamud: So do I have to go out there and say ​“Well, I like this piece of infor­ma­tion. I like that piece of infor­ma­tion.” Do I have to scour the world and build this world­view or is it some­how done dynam­i­cal­ly and auto­mat­i­cal­ly for me?

Neuman: Well that is in fact one of the prob­lems which Prospero address­es. We rec­og­nize that cer­tain­ly it’s imprac­ti­cal to require users to go out with­out the ben­e­fit of Prospero find­ing what they’re inter­est­ed in just so that they can pull that back into their view of the world. Instead, the way that things work is there are cer­tain peo­ple that have orga­nized infor­ma­tion already. And we believe that users should be able to con­struct their own vir­tu­al sys­tem by start­ing from exist­ing vir­tu­al sys­tems that oth­ers have cre­at­ed and cus­tomiz­ing them. And by tak­ing the best parts of dif­fer­ent vir­tu­al sys­tems and com­bin­ing them into their own view. 

Now how do they find the vir­tu­al sys­tems that they start from. Well, typ­i­cal­ly a user will start out with a vir­tu­al sys­tem that is set up for them by their site admin­is­tra­tor, for example.

Malamud: So there’s a default Prospero that we use? Is that how it works?

Neuman: Yeah. So your site might have default a Prospero, or a default vir­tu­al sys­tem that has been set up by your admin­is­tra­tor, know­ing that well you know, this is the chem­istry depart­ment so the peo­ple in this depart­ment are real­ly more inter­est­ed in things relat­ed to chem­istry instead of things relat­ed to com­put­er sci­ence, for exam­ple. Starting from this, you will have those things that it was expect­ed that you might be inter­est­ed in near­by. You can still get at all the stuff that’s there for com­put­er sci­ence, for exam­ple, but you’ve got to go through a few addi­tion­al hops. But as you find these things by explor­ing deep­er and deep­er in your own vir­tu­al sys­tem, you can forge new links and bring those pieces that you have decid­ed of inter­est clos­er to the cen­ter of your vir­tu­al system. 

Malamud: And you actu­al­ly— Let’s say you find some anony­mous FTP archive out there and it’s got a file of chem­i­cal abstracts. Do you make a copy of it and bring it back, or does Prospero know that it’s FTP-able and just get it when you point to it?

Neuman: Prospero knows that it’s FTP-able. You sim­ply make a link to it. Well first of all, as you’re explor­ing you might just say ​“I want it,” and you can say ​“cat file­name” if you’re in the file sys­tem inter­face. Or if you’re in the menu brows­er inter­face, you can sim­ply select the par­tic­u­lar item. 

One of the impor­tant things with Prospero—this is sort of an aside here—is that we’re not try­ing to pro­vide the user inter­face. We’re try­ing to pro­vide infra­struc­ture upon which dif­fer­ent appli­ca­tions can build. So for exam­ple, you brought up the ls inter­face. So you’re doing cd’s and ls’s and look­ing around. But that’s just one way of get­ting at this data. The same data you can access through a menu brows­er very sim­i­lar to the Gopher sys­tem. We have plans on adding a hyper­text brows­er. Already, Prospero is the way that most users out there get at infor­ma­tion that’s avail­able through the Archie data­base, although because Prospero pro­vides infra­struc­ture, most users don’t real­ize that because they just run the appli­ca­tion that they’re used to. 

Malamud: So they’re run­ning xarchie and they’re actu­al­ly talk­ing to Prospero?

Neuman: That is cor­rect. In fact—

Malamud: Well now how does that work?

Neuman: Xarchie is sim­ply an appli­ca­tion that has been built that makes calls to query the Archie data­base over the net­work using the Prospero pro­to­col. So, the Archie data­base is export­ed all by a Prospero serv­er on each of the pri­ma­ry Archie sites, in a form that looks like basi­cal­ly a mesh of infor­ma­tion or like a file sys­tem in some sense. Really it’s a direct­ed graph. You have indi­vid­ual nodes in the graph that cor­re­spond to direc­to­ries. You have nodes in the graph that cor­re­spond to files. You have links that bind cer­tain files and oth­er direc­to­ries in there. And you can have attrib­ut­es that are asso­ci­at­ed with indi­vid­ual files. 

So in fact, what hap­pens when xarchie makes a query, it goes off, deter­mines what it is that you want based on what par­tic­u­lar but­tons you clicked in the xarchie inter­face and the name of the file you spec­i­fied. It for­mu­lates that in the form of…well, here is a note in this direct­ed graph that cor­re­sponds to an Archie serv­er. And I know that by spec­i­fy­ing a cer­tain file name under this, I am going to get back the con­tents of a direc­to­ry that cor­re­sponds to the results of the query. And then it gets back that direc­to­ry which con­tains all the links that are in match­es to your query and presents them to the user. Information about file modes, last mod­i­fi­ca­tion times, are returned as attrib­ut­es that come back at the same time.

Malamud: So xarchie talks to Prospero, Prospero then talks to oth­er Archies and gets that infor­ma­tion back?

Neuman: Prospero then talks to Prospero servers that are run­ning on Archie sites. And the Prospero serv­er there makes a query to the local Archie data­base. And then returns the results as links and as direc­to­ries and as attrib­ut­es using the Prospero pro­to­col. In fact there is not a sep­a­rate pro­to­col to get at Archie. The only way to get at Archie over the net­work is through the Prospero pro­to­col or by tel­net­ing to Archie—

Malamud: Or emailing—

Neuman: Or by emailing.

Malamud: So you’re just a…you’re pro­vid­ing a net­work inter­face to the Archie world. Do you do that to oth­er worlds, like WAIS servers?

Neuman: Yes. In fact Alan Emtage has recently—or at least one of the oth­er peo­ple work­ing at Bunyip has in fact cre­at­ed a Prospero serv­er that will export a WAIS data­base. We just this sum­mer released a Prospero serv­er that pro­vides a gate­way to Gopher space. So in fact, the Gopher graph in some sense, or at least the Gopher hier­ar­chy that you go through if you’re going through Gopher, is in fact avail­able as a direct­ed graph using Prospero, with the par­tic­u­lar infor­ma­tion about links such as how you dis­play them, where they appear, as attrib­ut­es of those par­tic­u­lar links and of those par­tic­u­lar nodes in that direct­ed graph.

Malamud: Now why would I want to do that? Why would I want to add anoth­er… I’ve got a Gopher serv­er, I’ve got to Gopher client, why would I want to put a Prospero serv­er on top of my Gopher serv­er and come in that way? Isn’t that an extra lev­el of indirection?

Neuman: Yes. It is an extra lev­el of indi­rec­tion, and as you may have heard some peo­ple say well, any prob­lem in com­put­er sci­ence you can always solve with anoth­er lev­el of indi­rec­tion. In fact, that is what we need to do here because if you look at many of the ser­vices that are out there—you look at WAIS, you look at Gopher, you look at World Wide Web—these ser­vices are ver­ti­cal­ly inte­grat­ed. You have a Gopher serv­er, and you have a Gopher client. The Gopher client can access data on the Gopher serv­er. You have a World Wide Web serv­er, or a HTTP serv­er that’s out there, and you have a hyper­text client, and that hyper­text client can access the stuff that’s in the World Wide Web server. 

Malamud: What about Xmosaic? Isn’t that a mul­ti­ple inter­face client that hap­pens to talk World Wide Web but it also talks oth­er things?

Neuman: Um, in fact what you find peo­ple start­ing to do in many of these sit­u­a­tions is they are— Well there are sev­er­al approach­es that are being tak­en to address a prob­lem. One is gate­ways. And the idea behind a gate­way is that now all the infor­ma­tion from one ser­vice becomes avail­able to anoth­er. It gets trans­lat­ed in this inter­me­di­ate machine that’s a gateway. 

Also many of these appli­ca­tions that are out there will in fact under­stand mul­ti­ple data access pro­to­cols in some cas­es. So Xmosaic for exam­ple, and I’m not sure of the actu­al details with Xmosaic, but I believe it can go and retrieve a file by FTP, it can retrieve the file by HTTP. I don’t know if it can direct­ly retrieve a file by Gopher. It may be able to. 

Prospero pro­vides those func­tions at the data access lev­el as well. But I believe it’s impor­tant to have a more uni­form meta infor­ma­tion lev­el that allows you to export in a com­mon for­mat, direc­to­ry infor­ma­tion that is the rela­tion­ships between objects, attrib­ut­es about objects, and there are cer­tain­ly some oth­er approach­es or…given that approach there are cer­tain­ly some oth­er pro­to­cols you might con­sid­er for this. So for example—

Malamud: Sounds like X.500.

Neuman: Well, cer­tain­ly it sounds like X. 500. It sounds like…it sounds like…well why not use the Gopher pro­to­col? Or why not use the HTTP pro­to­col to do all this? 

Well, one of the prob­lems with some of the exist­ing ser­vices is that the pro­to­cols them­selves are too close­ly tied to the pre­sen­ta­tion. So, for the Gopher pro­to­col for exam­ple, the Gopher pro­to­col exports this meta infor­ma­tion with the assump­tion that you’re going to dis­play it using a menu brows­er. World Wide Web or HTTP exports direc­to­ry and meta infor­ma­tion with the assump­tion that you’re going to dis­play it as a hyper­text document. 

Well, in the case of the menu brows­er, that’s a lit­tle bit too restric­tive in the sense that there’s lots of stuff that you can’t real­ly rep­re­sent with­in a sim­ple menu pres­sure. For the hyper­text doc­u­ment it’s per­haps a bit…it’s not restric­tive enough. In the sense that it makes assump­tions that links to doc­u­ments, or links to objects are going to come out of the mid­dle of a doc­u­ment some­where. And this is dif­fi­cult for a menu brows­er to parse. 

So instead what you’d like to do is have a pro­to­col that export­ed the infor­ma­tion, the meta information—that is those links, the rela­tion­ships between the links, the attrib­ut­es describ­ing the links and describ­ing the objects—in a form that each appli­ca­tion can pick and choose those pieces that it needs. So the hyper­text brows­er, if you have a doc­u­ment that is a hyper­text doc­u­ment, the direc­to­ry should be able to spec­i­fy where those links are sup­posed to come out of in a doc­u­ment. But if you’re look­ing at the same doc­u­ment through a menu brows­er, it should then be able to just look at what those links are and not where specif­i­cal­ly in the doc­u­ment they are com­ing from. And fur­ther­more, there should be some meta infor­ma­tion asso­ci­at­ed with each link so it knows what to dis­play for the par­tic­u­lar menu item.

Malamud: In the World Wide Web, I can take a doc­u­ment and for­mat it in HGML and add that to my data­base and my serv­er goes out and pro­vides that infor­ma­tion to the World Wide Web envi­ron­ment. If there’s a Prospero serv­er on top it pro­vides it in that world. Do I ever for­mat a doc­u­ment for Prospero, or does Prospero we sit on top of anoth­er system?

Neuman: Prospero actu­al­ly sits between two parts of the sys­tem. It sits above the serv­er, or the data stor­age mech­a­nisms that are actu­al­ly stor­ing the data that infor­ma­tion providers want to make avail­able. And it sits below the appli­ca­tion that is going to access that data. So, one of the advan­tages of this is that if you have a bunch of appli­ca­tions, or a bunch of inter­faces to get this infor­ma­tion, they are then able to access all the infor­ma­tion export­ed by all the servers that export infor­ma­tion using Prospero. So, instead of hav­ing a sin­gle ver­ti­cal stack, the appli­ca­tions along the top should be able to get at all the data along the bottom. 

Now, the for­mat­ting of the data that you’re going to export should be for­mat­ted for spe­cif­ic appli­ca­tions, per­haps. Ideally you would like to pull out as much of the for­mat­ting infor­ma­tion as pos­si­ble and rep­re­sent it as attrib­ut­es so that that is actu­al­ly retriev­able direct­ly through Prospero. But, you may have dif­fer­ent rep­re­sen­ta­tions of the doc­u­ment for dif­fer­ent inter­faces. For exam­ple the idea with the hyper­text doc­u­ments and how you might rep­re­sent them using Prospero is that you can have an object in Prospero that is both a file and a direc­to­ry. The direc­to­ry con­tains those links to the oth­er doc­u­ments that are ref­er­enced from the hyper­text doc­u­ment. There can be attrib­ut­es asso­ci­at­ed with those links that say where the source of the link is with­in a doc­u­ment, if you’re using a hyper­text brows­er that is going to rep­re­sent the doc­u­ment that way. 

You don’t have the data asso­ci­at­ed with the object also, which is what you’re going to dis­play to the user. And you might use var­i­ous for­mats to rep­re­sent this data, whether it’s a PostScript doc­u­ment, or an ASCII text file, or an nroff doc­u­ment or some­thing else. 

Now, the type of the doc­u­ment or the for­mat of the doc­u­ment is also export­ed by Prospero as an attribute, what we call object inter­pre­ta­tion, so that the appli­ca­tion can decide how it is going to inter­pret that par­tic­u­lar doc­u­ment. But, for many types of doc­u­ments that are sim­ply text it’s still quite appro­pri­ate for a sim­ple brows­er that does­n’t under­stand HTML, for exam­ple, to dis­play it sim­ply as text. And then the attrib­ut­es that are on the links still allow it to describe where those links are using Prospero direct­ly, even though it does not under­stand how to inter­pret the embed­ded text that is with­in an HTML document.

Malamud: Are there mul­ti­ple peo­ple that have put togeth­er inter­faces to Prospero? I mean, can I run this on mul­ti­ple plat­forms? What… How do I run it?

Neuman: Right. So, we have sev­er­al releas­es of Prospero that are avail­able, some of which we’ve made avail­able, some of which oth­er peo­ple have done exten­sions to. Our basic release is avail­able from the machine pros​pero​.isi​.edu in the direc­to­ry /pub/prospero.

Malamud: Okay.

Neuman: You can read the readme file there and find out infor­ma­tion about which release you wan­na get. The releas­es that we dis­trib­ute run on most most vari­ants of the Unix oper­at­ing sys­tem. Version 4 of Prospero—we just recent­ly released ver­sion 5. Version 4 of Prospero, a num­ber of peo­ple, in par­tic­u­lar Brendan Kehoe who’s at Cygnus, took and stripped out a lot of the pieces that were not nec­es­sary for for exam­ple the stand­alone Archie client. And this ver­sion which he had then made avail­able was then in fact portable to even more machines. I believe it’s been port­ed to VMS and it’s been port­ed to MS-DOS and a few oth­er machines. We just recent­ly released ver­sion 5 and I expect we are going to start see­ing the same thing hap­pened with ver­sion 5. But right now the release that we’re pro­vid­ing is only writ­ten for Unix variants.

Malamud: But you dis­trib­ute source code, [crosstalk] it’s pub­licly avail­able and…

Neuman: Yes. It’s pub­licly avail­able source code writ­ten in ANSI C. It does require net­work sup­port for both the User Datagram Protocol and of course the select sys­tem call. Those are the two things that—

Malamud: But Prospero’s writ­ten in ANSI C, so Prospero is ANSI-compliant.

Neuman: Yes.

Malamud: Why do you call it Prospero?

Neuman: Well, Prospero was the prin­ci­pal char­ac­ter in The Tempest, by Shakespeare. And in The Tempest, when the ene­mies of Prospero were ship­wrecked on an island, through var­i­ous mag­ic he caused each of the mem­bers of the ship­wrecked par­ty to think that they were the only per­son on the island. And they did not have a shared view of every­thing until they slow­ly learned about the oth­er survivors. 

Malamud: Kerberos has been high­ly suc­cess­ful in fair­ly large net­works, but one can say that it seems to have found its place in the orga­ni­za­tion. In the MIT cam­pus net­work, in the cor­po­rate net­work. And it does­n’t seem to have scaled to the Internet as a whole. We’re look­ing at new tech­nolo­gies now like pub­lic key cryp­tog­ra­phy. Is that an alter­na­tive to Kerberos, or do the sys­tems from RSA and the sys­tems that Privacy-Enhanced Mail are based on, do those some­how fit in with Kerberos to pro­vide a secu­ri­ty solution?

Neuman: I think that the two are com­ple­men­tary. In fact, you are quite cor­rect that most of the use of Kerberos to date has been with­in a par­tic­u­lar orga­ni­za­tion. Now ver­sion 5 of Kerberos is scal­able. In fact you can orga­nize Kerberos realms—these are col­lec­tions of Kerberos users that are reg­is­tered in a com­mon data­base. You can orga­nize these realms so that users in one realm can in fact com­mu­ni­cate with and authen­ti­cate them­selves to ser­vices in anoth­er. And you can orga­nize realms hier­ar­chi­cal­ly along the lines of the domain name sys­tem, or in fact along sim­i­lar lines to the cer­ti­fi­ca­tion hier­ar­chies that you have in Privacy-Enhanced Mail.

Malamud: Should we do that instead of the cer­ti­fi­ca­tion hierarchies?

Neuman: No. I believe that— well, I believe that we will start to see hier­ar­chi­cal orga­ni­za­tions of Kerberos realms. But there are also ben­e­fits the pub­lic key cryp­tog­ra­phy. Kerberos is based on con­ven­tion­al cryp­tog­ra­phy, which has some lim­i­ta­tions, but it also has some ben­e­fits. In par­tic­u­lar con­ven­tion­al cryp­tog­ra­phy tends to perform—has bet­ter per­for­mance than pub­lic key cryptography. 

There are advan­tages to pub­lic key cryp­tog­ra­phy relat­ed pri­mar­i­ly to the fact that you do not have to store secret infor­ma­tion on a cen­tral serv­er. Whereas in Kerberos, although the cen­tral serv­er is some­thing that is pre­sum­ably much more eas­i­ly secured than your nor­mal work­sta­tion, there’s still the fact that the users’ keys are stored on it. 

So there are def­i­nite ben­e­fits to using pub­lic key cryp­tog­ra­phy. But they’re also def­i­nite costs to using. And what I see as the ide­al mix is you need to have both of these avail­able. And it is like­ly that over the course of the next cou­ple of years, we will in fact see authen­ti­ca­tion pro­to­cols in par­tic­u­lar per­haps some follow-ons to Kerberos that will pro­vide both Kerberos authen­ti­ca­tion, based on con­ven­tion­al cryp­tog­ra­phy, and authen­ti­ca­tion based on pub­lic key cryp­tog­ra­phy. And such a mech­a­nism will have the advan­tage that those users that can­not afford the cost in terms of per­for­mance of the pub­lic key encryp­tions can choose to use the pub­lic keys and still inter­op­er­ate with those users that are doing authen­ti­ca­tion based on these pub­lic key cer­ti­fi­ca­tion hierarchies. 

Additionally, for those sites that are not will­ing to install pub­lic key-based authen­ti­ca­tion for fear of either infring­ing on patents or for the desire not to have to pay the licens­ing fees for that, they too would then be able to make use of the con­ven­tion­al cryp­tog­ra­phy in one par­tic­u­lar vari­ant of Kerberos while still inter­op­er­at­ing with those that are mak­ing use of the pub­lic key cryp­tog­ra­phy as well.

So I see these things actu­al­ly com­ing clos­er togeth­er so that it is just sim­ply a choice of which form of cryp­tog­ra­phy you choose to use, and which cer­ti­fi­ca­tion hier­ar­chy you tend to use, whether that be the one that will be evolv­ing for Privacy-Enhanced Mail, or the con­ven­tion­al cryp­tog­ra­phy realm hier­ar­chies that are used for Kerberos. But these should all work togeth­er with­in a com­mon mech­a­nism in the long run, and I think we’re going to start to see that.

Malamud: I think the long run is maybe a key phrase right there. Security has been a long time in com­ing. We’ve had solu­tions like Kerberos, we’ve had the RSA-based pub­lic key cryp­tog­ra­phy. Yet for most of the glob­al Internet secu­ri­ty con­sists of typ­ing a pass­word in the clear for a tel­net ses­sion. Are you dis­ap­point­ed in how long it’s tak­en secu­ri­ty to deploy itself in the Internet?

Neuman: I’m some­what dis­ap­point­ed, but I’m not at all sur­prised. And the rea­son that— Well, there is one thing that we have not pro­vid­ed to the appli­ca­tion devel­op­ers that I think would def­i­nite­ly improve their abil­i­ty to inte­grate secu­ri­ty with their appli­ca­tions. And that is that right now, inte­grat­ing secu­ri­ty mech­a­nisms with­in appli­ca­tions is pret­ty dif­fi­cult. You have to go and mod­i­fy the appli­ca­tion to make calls to the secu­ri­ty ser­vices, then send across cre­den­tials to the oth­er side, pass them into a func­tion there. You have to actu­al­ly go in and mod­i­fy these pro­to­cols and these mech­a­nisms at a pret­ty low level. 

Now, there’s work such as the GSSAPI—the Generic Security Services Programming Interface, which allows you to do this once for an appli­ca­tion, and then that pre­sum­ably works for a vari­ety of authen­ti­ca­tion mech­a­nisms, but there’s still that ini­tial hur­dle of going in and chang­ing the exist­ing appli­ca­tions. If we had a ser­vice such that you just relinked your appli­ca­tion with this library and all of a sud­den every­thing was secure, that would be the ide­al world because it would be easy to inte­grate it with new applications. 

One of the things that I would real­ly like to see, and it’s some­thing that I’ve been doing, is as peo­ple design new appli­ca­tions, they should think about secu­ri­ty up front. And they should include at least the hooks in the mech­a­nism so that they can be eas­i­ly inte­grat­ed with secu­ri­ty pro­to­cols. For exam­ple, Prospero which is a direc­to­ry ser­vice, cur­rent­ly sup­ports four kind of authen­ti­ca­tion. It’s sup­ports ver­sion 5 of Kerberos, but rec­og­niz­ing of course that most sites do not yet have Kerberos set up. It also sup­ports pass­word authen­ti­ca­tion. It also sup­ports authen­ti­ca­tion based on the Internet address from which you’re com­ing and the user name. 

Malamud: So you think it’s up to the appli­ca­tion design­ers to begin work­ing much more inten­sive­ly in this area rather than wait­ing for some secu­ri­ty guru to come up with a mag­ic bullet.

Neuman: I think that new appli­ca­tion design­ers need to con­sid­er secu­ri­ty from day one. Because well, even if you had this mag­ic bul­let there are cer­tain issues which can­not be han­dled just by relink­ing with a library. In par­tic­u­lar, Prospero has support—and the Andrew File System is anoth­er example—has sup­port for access con­trol lists, fair­ly flex­i­ble access con­trol lists. That is some­thing that you need to think about in your ser­vice mod­el that can­not just be obtained by pro­vid­ing a library; in par­tic­u­lar you need the abil­i­ty to store access con­trol lists and asso­ciate them with par­tic­u­lar objects. The pro­to­col mes­sages that’re involved for exchang­ing secu­ri­ty infor­ma­tion in Prospero, that is some­thing that I designed into Prospero but some­thing that might in—one of these days if one of these mag­ic bul­lets came along, one of these libraries you can link with—might in fact sup­plant some of that. But for the time being I would say don’t wait on that. If you are design­ing a new appli­ca­tion or a new pro­to­col, think secu­ri­ty up front. At least in the IETF there’s now a require­ment for new RFCs to have a sec­tion with secu­ri­ty con­sid­er­a­tions. And one of the ideas behind that was to put the peo­ple design­ing these new pro­to­cols at least in touch with peo­ple in the Security Area Advisory Group so that they can be brought up to speed on what is avail­able out there and what issues they should be think­ing of up front.

Malamud: Is that working?

Neuman: That seems to be work­ing. Although we do see a lot of secu­ri­ty con­sid­er­a­tions which sim­ply state ​“There are none.” Or, ​“This doc­u­ment is entire­ly about secu­ri­ty.” But, at least it has giv­en us the oppor­tu­ni­ty when peo­ple start look­ing at new pro­to­cols to speak to them and say well here’s what’s avail­able; here are some hooks that you should stick in even if the things are not avail­able yet.

Malamud: Well thank you very much. We’ve been talk­ing to Cliff Neuman. 

This is Internet Talk Radio, flame of the Internet. You’ve been lis­ten­ing to Geek of the Week. You may copy this pro­gram to any medi­um, and change the encod­ing, but may not alter the data or sell the con­tents. To pur­chase an audio cas­sette of this pro­gram, send mail to radio@​ora.​com.

Support for Geek of the Week comes from Sun Microsystems. Sun, the net­work is the com­put­er. Support for Geek of the Week also comes from O’Reilly & Associates, pub­lish­ers of the Global Network Navigator, your online hyper­text mag­a­zine. For more infor­ma­tion, send mail to info@​gnn.​com. Network con­nec­tiv­i­ty for the Internet Multicasting Service is pro­vid­ed by MFS DataNet and by UUNET Technologies.

Executive Producer for Geek of the Week is Martin Lucas. Production Manager is James Roland. Rick Dunbar and Curtis Generous are the sysad­mins. This is Carl Malamud for the Internet Multicasting Service, town crier to the glob­al village.