eric@ists.ists.ca (Eric M. Carroll) (04/10/89)
While pondering the vulnerabilities that we are about to expose ourselves to when we connect up to the Internet, I have been left with some questions about the believability of IP addresses. Namely, most bsd/sunOs authentication is done on the basis of host name (ie ip address) then (sometimes) uid. UID authentication is clearly meaningless. But given a packet coming in to my machine with a forged IP source address, what are the chances of an attacker actually establishing a real tcp connection? What UDP based services would *not* require a response to work (ie what could he do blind)? What conditions would be required to allow the attacker to sucessfully represent themselves as another host? A first cut look at the problem suggests that in the world of routers, forged IP address can be delivered to the target but responses don't get returned to the attacker. A one-way connection. Looks useless at first glance. Any comments or paper references would be appreciated. Email to me, and I will summarize. Thanks.
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (04/11/89)
In article <376@ists.ists.ca> eric@ists.ists.ca (Eric M. Carroll) writes: > >A first cut look at the problem suggests that in the world of routers, >forged IP address can be delivered to the target but responses don't >get returned to the attacker. A one-way connection. Looks useless at >first glance. > Seems to me that if the router follows source routing and the host follows source routing (as required by the Gateway and Hosts (draft) RFCs) that you can easily spoof IP source addresses. If this is true, why is source routing required and not optional? Shouldn't I be allowed to turn it off if I worry about the veracity of source addresses, or I want to implement security levels that vary by subnet? Kent England, Boston University
hedrick@geneva.rutgers.edu (Charles Hedrick) (04/11/89)
Yes, with source routing you can fake IP addresses in such a way that you get a two-way conversation going to the wrong place. For that reason, our gateways drop any packet that uses source routing. I'm looking into a more selective approach, but for the moment this seems the safest. However even the ability to fake source addresses leaves the possibility of some damage. Some servers (e.g. some options of YP, maybe also named) may allow you to change a database with a single packet. The fact that you don't get an ACK doesn't necessarily prevent the damage from being done. This suggests that RPC servers that make significant changes should require passwords or some other validation. Furthermore, I'll bet I could find a way to open a TCP connection even if I don't get the ack's back. Probably I couldn't keep it open very long, but I might get enough data through to do an rsh. It would require some intelligent guessing of what sequence numbers you're using, and probably a good deal of redundant traffic. Eventually I'm probably going to make our external gateways check source addresses of packets they forward. The idea would be to refuse to allow packets into Rutgers from the outside with Rutgers source addresses. However in the end we're probably going to want encryption-based validation for everything. I think even with kludges in the gateways, the days are numbered for security based on source addresses.
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (04/12/89)
In article <Apr.10.23.46.46.1989.12488@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes: >Yes, with source routing you can fake IP addresses in such a way that >you get a two-way conversation going to the wrong place. > [...] > However in the end we're probably going to want >encryption-based validation for everything. I think even with kludges >in the gateways, the days are numbered for security based on source >addresses. I agree that encryption-based validation is important, but we still want to be sure that the unencrypted data follows specific (in some sense secure) routes. I think TOS is the way to do this, but until then I can structure my subnets in such a way that, with some physical security, I have some assurance that unencrypted, sensitive data cannot easily be snooped off the net. I would not want to allow someone with genuine Kerberos-authenticated access to login from an "open" subnet. I would want some assurance that the data stream is following routes controlled by the routers and not by the hosts. (Another argument against source routing :-) Is this reasonable? Kent England, BU
jon@athena.mit.edu (Jon A. Rochlis) (04/12/89)
In article <29455@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: > I would not want to allow someone with genuine >Kerberos-authenticated access to login from an "open" subnet. I would >want some assurance that the data stream is following routes >controlled by the routers and not by the hosts. (Another argument >against source routing :-) > > Is this reasonable? I don't think so. What does an "open" subnet mean? Remember the model we're working with here. The path from client to server may span several networks and pass through several (many) routers each possibly under different (and potentially hostile) administrative control. You cannot say (now or for very long in the future) that you only allow access to your campus resources from some "secure" subnets which you in some fashion control. If a professor from BU wants to log into an MIT colleague's machine using Kerberos am I supposed to disallow that because I don't control the BU subnet he's coming from, the routers in the path on the BU backbone, or the NEARNet backbone/routers? What if he's coming in over the NSFnet? It's the "principal" who's accessing the data, not the machine he's currently using. Where the ends of the converstation or the path the packets take shouldn't matter. [Some information may be too sensitive for this, but that should be the exception for quite a while. No classified on the Internet, right!] The only real solution is an end-to-end approach using something other than addresses for authentication. -- Jon
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (04/12/89)
In article <10526@bloom-beacon.MIT.EDU> jon@mit.edu (Jon A. Rochlis) writes: >In article <29455@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: > >> I would not want to allow someone with genuine >>Kerberos-authenticated access to login from an "open" subnet. I would >>want some assurance that the data stream is following routes >>controlled by the routers and not by the hosts. (Another argument >>against source routing :-) >> >> Is this reasonable? > >I don't think so. What does an "open" subnet mean? I should have known better than to toss that off-the-cuff. So, Jon takes me to task. :-) How about we call a subnet "open" if it has no special security features; no control over nodes, etc? Ie, subject to packet snooping by anyone on the subnet. > >Remember the model we're working with here. The path from client to >server may span several networks and pass through several (many) >routers each possibly under different (and potentially hostile) >administrative control. > I was thinking of a much simpler case where I might be able to secure a subset of subnets under my control and protect data in transit from snooping. I think this is a common case in many institutions. If some data paths could be "secured" to some degree from snooping and all hosts on a "secure" subnet could be maintained by administrators to some level of security, etc, we might be able to achieve some measure of protection against snooping for communication between "secure" hosts. > >The only real solution is an end-to-end approach using something other >than addresses for authentication. > > -- Jon True, but assuming that full data encryption is too expensive in terms of performance and software, perhaps I could implement a limited security model consisting of "secure" subnets and "secure" routing that would provide enough protection against snooping that I could get my administrative users on the network and get their auditors off my back. :-) So, if I set-up "secure" subnets with hosts that are "sanitized" to some degree, and I have some level of physical security on these subnets, and I use Kerberos to protect passwords, and I turn off source routing in secure hosts and all routers, and secure hosts do some address checking to keep sensitive data from transiting open subnets, do I have something worth having, ie a modest level of security sufficient to fulfill my obligations to protect data and yet still allow these applications to use network technology?
dla@athena.mit.edu (Don Alvarez) (04/12/89)
In article <29475@bu-cs.BU.EDU> kwe@buit13.bu.edu (Kent England) writes: > ... assuming that full data encryption is too expensive >in terms of performance and software, perhaps I could implement a >limited security model consisting of "secure" subnets and "secure" >routing that would provide enough protection against snooping that I >could get my administrative users on the network and get their >auditors off my back. :-) > > So, if I set-up "secure" subnets with hosts that are >"sanitized" to some degree, and I have some level of physical security >on these subnets, and I use Kerberos to protect passwords, and I turn >off source routing in secure hosts and all routers, and secure hosts >do some address checking to keep sensitive data from transiting open >subnets, do I have something worth having, ie a modest level of >security sufficient to fulfill my obligations to protect data and yet >still allow these applications to use network technology? No. You don't have anything worth having. All I need is an IBM-PC ($0.10/dozen), an ethernet card ($0.20/dozen), and a vampire tap ($0.50/ dozen), and I can listen to ANYTHING I want to on your "secure" subnet. As you leave your office today, look at the yellow or orange cable running all over your building/campus and tell me that you can secure every inch of it. It may sound far-fetched for a student to be running around with an ethernet card and a vampire tap today, but in five years the statement "nobody can tap ethernet because they don't have the hardware" will sound like "9600 baud lines are secure because no hackers can afford 9600 baud modems." I can already buy everything I need to tap your ethernet for just over $1000, and prices are dropping fast. Remember that any network you would want to secure, someone else would want to tap. Unless you can see every inch of your ethernet cable at the same time, and can put it all behind the same locked door, you don't have a secure subnet. If you can secure it, and if enough of your traffic is internel to that subnet to make your special internal protocol worthwhile, then your best bet is almost certainly to do as the romans do and not allow any external connections to your subnet. -Don boomer@space.mit.edu MIT Center for Space Research
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (04/13/89)
Using IP source addresses for authentication doesn't work. In fact, I just finished a paper which has that as one of its major subthemes; it will appear in the April 1989 issue of ``Computer Communication Review''. There are many attacks possible on hosts which believe such address, and Chuck Hedrick is absolutely correct that one need not hear responses to a TCP connection request to do harm; details are in the paper. (Note: I didn't invent that attack, though I did generalize it a bit.) In the very near future, we're going to have to use encryption-based authentication; it's the *only* way. --Steve Bellovin smb@ulysses.att.com att!ulysses!smb
scc@cl.cam.ac.uk (Stephen Crawley) (04/13/89)
Kent England suggests that it is possible to prevent ether snooping
in many cases, and that this can be used to give ``a modest level of
security sufficient to fulfill [his] obligations to protect data and
yet still allow [] applications to use network technology''
Kent, how do you propose to stop J R User from unplugging his Sun and
plugging in a PC to run an etherspy?
The only way to prevent etherspying is to:
1) place all ethernet wire and any machine attached to it in a physically
secured area and post a guard to keep out anyone who you can't trust 100%,
2) make sure that all machines on the ethernet accessible from outside
the secured area run a verified secure operating system.
These restrictions are just not practical in an academic environment, and in
most other environments too.
I put it to you that your ``modest degree of security'' is actually
no security worth speaking of.
-- Stevekwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (04/14/89)
In article <10540@bloom-beacon.MIT.EDU> boomer@space.mit.edu (Don Alvarez) writes: >> >> So, if I set-up "secure" subnets with hosts that are >>"sanitized" to some degree, and I have some level of physical security >>on these subnets, and I use Kerberos to protect passwords, and I turn > >No. You don't have anything worth having. All I need is an IBM-PC >($0.10/dozen), an ethernet card ($0.20/dozen), and a vampire tap ($0.50/ >dozen), and I can listen to ANYTHING I want to on your "secure" subnet. >As you leave your office today, look at the yellow or orange cable running >all over your building/campus and tell me that you can secure every inch of it. Of course I would not think of using that yellow or orange cable for a secure subnet. I don't like that cable for open subnets- it's too hard to manage in an office environment. But I can think of several techniques to install relatively secure Ethernet subnets. My secure subnet might be a delni in a locked equipment rack. I could even say that my twisted pair Ethernet subnets are sufficiently secure against snooping under certain extra conditions. And if that isn't good enough, fiber today is as easy to install as thin coax (though not as cost effective), so I could spec fiber. I am not trying to secure my nets against the KGB, so don't tell me you can crack any net I design and install. I just want a reasonable level of physical security, like I require of my backbone nets. I could spec conduits if I had to, but that is taking things too far. I would spec link level encryption first.
scc@cl.cam.ac.uk (Stephen Crawley) (04/14/89)
Kent England writes: > My secure subnet might be a delni in a locked equipment rack. Are the computers inside the locked equipment rack as well? If not, what is to stop JR User from plugging a PC into a drop cable? Suppose that you do put the computers in the locked rack, how do your users access the machines? Lots of 9600 baud async lines? [You can't provide terminal over your LAN without sending network traffic off your physically secure subnet!] What are you going to say to the users who want to use a PC or a workstation? Do the physically secure machines on the LAN run a secure OS? If not, what is to stop JR Hacker from indulging in a bit of unauthorised spade work on the OS kernel to give himself access to ethernet packets? [Don't tell me that JR Hacker =/= JR User. What if he is and you don't know about it? What if he is and you DO know about it?!] What are you going to say to your users who want to use ... say ... UNIX? > I am not trying to secure my nets against the KGB, so don't tell me > you can crack any net I design and install. Just who are you trying to make the system secure against? Cleaning ladies? An undergraduate CS hacker wouldn't have much trouble finding a way through your scheme ... given a big enough carrot. Certainly the undergrads around here wouldn't! I want security that is on the same level as me keeping sensitive materials in a locked filing cabinet inside a locked office with the nightwatchman walking the corridors. At the same time I want to use a nice bitmapped workstation with several MIPs of local processing power [In 5-10 years time I'll expect an integrated services workstation.] I do NOT want to be forced to use a klunky old 24 by 80 on a 9600 baud terminal line. I do NOT want to have to go down the corridor to the secure room every time I want to read my email. I claim that security without substantial inconvenience is achievable using encrypted protocols, but not with a physical security scheme. -- Steve
vjs@rhyolite.SGI.COM (Vernon Schryver) (04/15/89)
In article <710@scaup.cl.cam.ac.uk>, scc@cl.cam.ac.uk (Stephen Crawley) writes: > Kent England writes: > > My secure subnet might be a delni in a locked equipment rack. > > Do the physically secure machines on the LAN run a secure OS? If not, > what is to stop JR Hacker from indulging in a bit of unauthorised spade > work on the OS kernel to give himself access to ethernet packets? Why dig up the kernel? More than one workstation vendor provides standard tools to send and receive arbitrary ethernet packets. Remember nit, tcpdump, and etherfind from one of those vendors. Others have what they consider better. Many paying customers think they require raw ether for real applications (i.e. something they'll pay for). Vernon Schryver Silicon Graphics vjs@sgi.com
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (04/15/89)
In article <709@scaup.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes: > >I put it to you that your ``modest degree of security'' is actually >no security worth speaking of. > With no flame intended (since you are so polite in your response): I put it to you that this objection that "security" without total "security" is no security is a way to do nothing, when something needs to be done. I must start somewhere and I don't intend to be put off by this kind of argument. I should say that one of the things we don't mention often enough is that any discussion of security needs to talk specifically about the threat that is being countered. I am as guilty as anyone in not explicitly defining the threats I think need to be countered. No one knows exactly what threat they are faced with. Perhaps they have an idea, when presented with a threat scenario, whether they think they must counter it. While I don't know exactly what threats I am faced with, I know that applying reasonable measures will result in a winnowing of the threat "pool". Doing nothing results in nothing being done. Of course, doing something does not guarantee that anything useful has been accomplished and for that reason I appreciate everyone's comments, recommendations, and pointers. Thanks.
cyrus@pprg.unm.edu (Tait Cyrus) (04/15/89)
In article <709@scaup.cl.cam.ac.uk> Kent writes: >Kent, how do you propose to stop J R User from unplugging his Sun and >plugging in a PC to run an etherspy? Why go to that trouble. I use a Sun ALL the time to do 'ether' snooping. It is faster than a PC AND I can still get "real-work" done while it is snooping. Since it is unrealistic to assume you can keep every "J R User" from gaining access to your net (either physical access where they can attach a "device" or logical access via an already attached machine (SUN/PC) ) the only way to make sure you have authentication of hosts is some kind of encryption. The question is at what layer. If, and that is a BIG IF, you put your cable in a "special" pressurized conduit, AND you can trust EVERY user that has an account on ALL machines connected to this "special" cable, THEN you have a secure network. As soon as ONE of those users does something they are not supposed to (i.e. run a snooper on a Sun attached to this network), THEN your net security is shot. If you use encryption, you can do some good, but that encryption will have to be below the network layer. If you put it at the network layer, a snooper still knows who is talking to whom and that, in a lot of cases, is enough information to allow "someone" to cause damage to your net or gain information they are not supposed to have access to. Even if you put it at the LLC layer, a snooper still knows who is talking to whom and there is a lot of information in just knowing that. Now you can argue that encryption at the network layer, or above, is sufficient because even if someone "steps into a conversation", they still don't know what the data content is. With the new 10-20 MIP machines available, this would be a trivial task, depending on the method of encryption of course, to break the crypt and gain access to the data. On the extreme case, what if "someone" dumps a conversation to disk for later analysis. If you want to to keep people from being able to break your data, you will have to use such a high level of encryption that just encrypting/decrypting the data will take so long that it would make your network useless. The only way around it is to say that you will use a moderately complicated encryption algorithm (fairly fast for encrypting/decrypting). Even though someone can break this crypt in a day or two, and assuming they store the conversation to disk, the data will be so old that it will not do them much good. You will, of course, have to change keys fairly often (once a day). >-- Steve --- W. Tait Cyrus (505) 277-0806 e-mail: cyrus@pprg.unm.edu University of New Mexico Dept. of Electrical and Computer Engineering Parallel Processing Research Group Albuquerque, New Mexico 87131
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (04/16/89)
In article <29624@bu-cs.BU.EDU>, kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) writes: > I put it to you that this objection that "security" without total > "security" is no security is a way to do nothing, when something needs > to be done. .... > I should say that one of the things we don't mention often > enough is that any discussion of security needs to talk specifically > about the threat that is being countered. I am as guilty as anyone in > not explicitly defining the threats I think need to be countered. Kent refers to two crucial points: that network security is just one aspect, and that one must assess the threats before doing anything. Let me add a few more points from a canned security lecture I give on occasion: levels of security should be consistent, and that security is always a tradeoff with convenience. In my environment -- a research-oriented department within AT&T Bell Laboratories -- I'm primarily concerned with intrusions from the outside. More specifically, I'm concerned with preventing initial break-ins, and with containing an intruder within a single compromised machine, and preventing the infection from spreading. Consequently, physical security -- i.e., keeping curious fingers away from our Ethernets -- is a rather minor concern. Anyone inside who is intent on doing damage could do far more, far more easily, than by adding yet another tap. But networks and password capture are great ways for an intruder to take over more machines; consequently, I'm concerned about IP security -- and as I've said, I feel it provides none -- and about host-based security measures such as login-spoofers and easily-guessed passwords. A corollary to this is that I need to keep cleartext passwords off of the Ethernet because of the existence of programs like etherfind. (There are other, more subtle, ways to spy on network connections; they're outlined in my paper.) Other environments -- i.e., universities, or high-security military places -- need to pay far more attention to physical security issues. But that doesn't mean that they can neglect the others. Kerberos is a very good start, though I have serious reservations about some aspects of it. (For example, I think too little consideration is given to fake login programs building a collection of passwords.) And the (current) inability to forward a ticket is inconvenient at times when one is rlogin'ed to a host and wishes to do a network operation.
henry@utzoo.uucp (Henry Spencer) (04/18/89)
In article <709@scaup.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes: >Kent England suggests that it is possible to prevent ether snooping >in many cases, and that this can be used to give ``a modest level of >security sufficient to fulfill [his] obligations to protect data and >yet still allow [] applications to use network technology'' > >Kent, how do you propose to stop J R User from unplugging his Sun and >plugging in a PC to run an etherspy? If he's using Ethernet to connect Suns in offices and terminal rooms, he can't. If, on the other hand, it's simply the interconnect within a central computing facility, then the situation is not so bad. Yes, it can always be done by someone with the right tools and knowledge -- but in most places, such people are relatively rare. The key question is, what level of threat are you trying to defend against? If all you want is to stop casual nosiness by J R User, Kent's approach may be reasonable. Even if JRU knows how to tap an Ethernet -- and if it's thick cable, the chances are pretty good that he doesn't -- he is going to be reluctant to walk into a facility where he is an unauthorized outsider and start pulling up floor tiles and messing with cables underneath. Likewise, he's going to be reluctant to disconnect existing transceiver cables, for fear that he'll disrupt ongoing activities badly enough for the Cable Police to come charging in the door. No, it's not going to stop a determined and knowledgeable intruder who is willing to take some risks, but that's a different level of threat and a rather less common one. Switching to encryption-based schemes will thwart him, but it is much more costly in several ways. In a relatively friendly environment, it may not be cost-effective. >I put it to you that your ``modest degree of security'' is actually >no security worth speaking of. It depends on what level of threat we are speaking of, and on details of the environment (e.g. where existing taps are). Don't dismiss it as "no security worth speaking of" just because it wouldn't stop the NSA. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (04/18/89)
In article <710@scaup.cl.cam.ac.uk> scc@cl.cam.ac.uk (Stephen Crawley) writes: >I want security that is on the same level as me keeping sensitive >materials in a locked filing cabinet inside a locked office with the >nightwatchman walking the corridors... Gee, you mean one of those filing cabinets whose locks can be picked with a paperclip? Inside an office that opens to a master key that the janitor has? The nightwatchman is actually very useful, I can have him hold the door for me as I walk out with an armload of papers. Let us not kid ourselves. An awful lot of non-computer security rests primarily on the rarity of determined and sophisticated intruders. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
7thSon@SLCS.SLB.COM (Chris Garrigues) (04/19/89)
It seems to me that Kent is working on the theory that: "Locks are to keep honest people honest; no amount of security which we can afford will keep out anybody who truely wants to cause trouble anyway." If he's going to take this approach, he needs to plug anything which is easy to get into , but he also has to be careful not to put in enough security to make it "an interesting challenge" for someone who would otherwise not bother. Chris
ingoldsb@ctycal.COM (Terry Ingoldsby) (04/23/89)
Other people have offered their ideas on how to secure a network (whether it
is TCP-IP, DECNet or XNS is unimportant). Here is my idea. Shoot it down if
you can think of a good way to break it:
This is derived on something I read in BYTE some time ago. I don
remember what issue.
Each authorized node has a file of a reasonably large size, say 100K,
filled with random numbers. Make them really unpredictable (they don't
necessarily have to satisfy any particular distribution). Protect both
files, so only privileged processes can read them (if you can't
trust superusers, your security is shot anyway). Each side of the
connection gets to ask the other side 3 questions. The questions are
of the form:
What number is at position 32156?
The number at position 2154 is 3261. True or False.
It is unpredictable what the indices of the questions will be, so just
listening to one session won't give you the answers you need for the
next session. The second type of the question is particularly good,
since if the answer is false, the eavesdropper still doesn't know what
the value at position 2154 is.
Each side gets a chance to decide if the other side is authentic. Once
authentication has been established, the initiator suggests that both
sides use the D.E.S. (Data Encryption Standard) key found at index ###.
From that point on, all communication is DES encrypted. There are
cheap chips to do that for you, so the overhead needn't be high.
Periodically, change the file at all nodes. If anyone is eavesdropping,
they won't have sufficient sessions to observe to deduce the contents
of the mystery file.
Is that secure enough?
Terry Ingoldsby
Land Related Information Systems
The City of Calgary
ctycal!ingoldsb@calgary.UUCP
or
...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsbbob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (04/26/89)
In article <291@ctycal.UUCP> ingoldsb@ctycal.COM (Terry Ingoldsby) writes:
This is derived on something I read in BYTE some time ago.
(...surely a reputable authority on the management on large networks
of modern machines :-)
Protect both files, so only privileged processes can read them (if
you can't trust superusers, your security is shot anyway).
I trust superusers on consoles of hosts that are locked in our machine
room. I don't trust superusers anywhere else. MIT publishes their
workstations' root password in their lab guides.
"Shot" host security is different from "shot" network security, and
"shot" remote host security is different from "shot" local host
security. I want to maintain some semblance of security on our
systems, and I do that by assuming (recognizing?) that the network and
all the other systems on it are insecure.budden@manta.NOSC.MIL (Rex A. Buddenberg) (04/29/89)
In article <291@ctycal.UUCP> ingoldsb@ctycal.COM (Terry Ingoldsby) writes: > >necessarily have to satisfy any particular distribution). Protect both >files, so only privileged processes can read them (if you can't >trust superusers, your security is shot anyway). Each side of the > Jerry Whitworth was a superuser.