Inter-Office MemorandumToIFS and Grapevine administratorsDateAugust 24, 1982FromEd TaftLocationPARC/CSLSubjectAccess controls (2nd edition)File[Indigo]AccessControls.bravoXEROX In recent years, the Xerox Research Internet has grown to encompass a large number oforganizations, including some outside the United States. Because of this, it is no longer possible toignore the necessity of controlling access to electronic information resources within the Internet.In this memo, we outline the information security requirements that must be met, and then describethe procedures for achieving them by means of the IFS and Grapevine access control mechanisms.This discussion assumes a world in which all users are registered in Grapevine and all IFSs useGrapevine for authentication and access control. This is not yet the case. Organizations that havenot yet converted are strongly encouraged to do so, since fulfilling the information securityrequirements is difficult or impossible without the mechanisms provided by Grapevine.While this memo focusses on information stored in files on IFSs, much of the material is of moregeneral relevance and applies to electronic and non-electronic information of all kinds.These policies and procedures have been developed by a committee consisting of Andrew Birrell,Jerry Elkind, Mike Schroeder, and Ed Taft.Changes since the March 13 edition: A new category of people has been defined, temporary visaemployees and affiliates, along with guidelines on such people's access to electronic information. TheAuto registry has been created for registering Grapevine individuals which represent machines orprograms.1. Xerox information security requirementsWithin Xerox, information is classified into five categories:1.Public-domain informationthat which has been formally cleared for public releaseoutside Xerox.2.Proprietary informationall information not cleared for public release but not includedin one of the following more restricted categories.3.Private datainformation whose unauthorized disclosure could have a substantialdetrimental effect on the operations of the company.4.Registered datainformation whose unauthorized disclosure could cause serious damageto the operations of the company.5.Personal datainformation of a sensitive, personal nature.]gpi c8q]rX-q3r \q]r-q3r VDq]r-q3!Osr IC HM F Y CF B%9% ?A[ =K <8D :U 7Q 6KX 3g P 1* .t#ru -zr= +8( *r %tX* #r=y u r5 yu r3/3yJur < 4yu r9]!yxur2 1>QZ Access controls (2nd edition)2Information in the last two categories is subject to very stringent regulations on how it may bedisseminated and stored. Since relatively few people have occasion to deal with registered andpersonal data, we shall concentrate on the other three categories. For information on correcthandling of registered or personal data, consult your manager or your Security Coordinator.For each category, there are guidelines for how the flow of that information should be controlled.Some of these guidelines are intended to protect Xerox proprietary concerns, while others areimposed by U.S. Government regulations.For the purpose of describing appropriate degrees of access to Xerox information, we divide theuniverse of people into five groups:1.U.S. employees and affiliatesU.S. citizens and permanent residents who are employeesof Xerox organizations and subsidiaries in the U.S., and other U.S. citizens orpermanent residents who have signed non-disclosure agreements with Xerox. This alsoincludes employees of Xerox organizations in Canada.2.U.S. non-affiliatesU.S. citizens and permanent residents not in category 1.3.Foreign affiliatesforeign nationals who are employees of Xerox Corporation or Xeroxforeign subsidiaries, and who are located outside the U.S.4.Temporary visa employees and affiliatesforeign nationals working in the U.S. undertemporary visas, who are employees of Xerox Corporation or of Xerox foreignsubsidiaries.5.Foreign non-affiliatesforeign nationals not in categories 3 and 4.Persons in each of these groups are permitted access to categories of information on the followingbasis:1.U.S. employees and affiliates:a.may have unrestricted access to public-domain and proprietary information;b.may be given access to private data on a need-to-know basis.2.U.S. non-affiliates:a.may be given access only to public-domain information.3.Foreign affiliates:a.may have access to public-domain information;b.may have access to proprietary information on a per-project basis only; project-wideapproval by the International Deputy is required (see section 5.1), and informationtransfers require Export Control Coordinator approval and any other approvals thatthe organization owning'' the information decides are appropriate;c.may be given access to private data on a need-to-know basis; project-wide approvalby the International Deputy is required, and information transfers require ExportControl Coordinator approval (see section 5.1) and the other approval associatedwith private data information.d.A record must be kept by the Export Control Coordinator of all transfers of non-public-domain information to foreign affiliates; the procedure for this is outlined insection 3.3. frXG b)7 `F _ P ]= Z8* Y)V W' TB S<$yPWur8N .!MO= q K4yI-rur9yFHur0D:yAu'r! @[")> y;ur- 9 B 7y4;1`u ru r ;.`ury+;)`u r y&,;#G`u r ; b`u r'b0#bZur1bD;`ur4bm,urb2be;`:b>bx  1?QYCAccess controls (2nd edition)34.Temporary visa employees and affiliates:a.may have unrestricted access to public-domain information;b.may have access to proprietary information in categories authorized in writing bythe employee's Xerox manager, as described below in (d);c.may be given access to private data on a need-to-know basis as authorized inwriting by the employee's Xerox manager, as described below in (d);d.must have their access to proprietary and private data controlled and documentedaccording to the procedure presented in section 3.4. This procedure requires thatan authorization memo be written by the employee's Xerox manager when theemployee starts work as part of a Xerox group, stating the term of employment, theprogram(s) the employee will be working on, and the categories of technicalinformation to which the employee will have access;e.must execute a non-disclosure agreement with Xerox, as discussed in section 3.4;f.may not take technical data out of the U.S. unless it has been logged, recorded, andapproved in accordance with our export control regulations. A temporary visaemployee who leaves the U.S. immediately reverts to the foreign affiliate status,with all its incumbent restrictions.5.Foreign non-affiliates:a.may be given access only to public-domain information;b.must not individually be on the U.S. Government denial list or members oforganizations or countries on this list.c.A record must be kept of all transfers of information to foreign non-affiliatesexcept Canadians; this includes all technical information, even though in the publicdomain.2. Organization of access controlsNow we review the mechanisms that exist for controlling access to electronic information in theXerox Research Internet.To begin with, it should be understood that the Internet is designed to permit any connectedmachine to communicate with any other, without any controls or restrictions. Since the Internetextends outside the U.S., this enables unrestricted international communication. Any requiredrestrictions on information transfer are the responsibility of the end parties of the communication,not of the Internet.2.1. Basics of access controlThe principal means of ensuring that a certain piece of information can be accessed only by certainindividuals is by attaching an access control list to the information and by requiring that individualsbe authenticated. Let us consider what this means.An access control list is simply a list of names of individuals who are to be granted access to theassociated information. For example, a file stored on a file server has a protection which, simplyput, is an access control list that determines who may access the file. Upon each attempted access,the file server checks the name of the individual requesting access against the file's access controllist, and permits the operation to proceed only if a match is found. This is entirely the server'sresponsibility, though the server can delegate some of the work to other servers as will be discussed frXGyb(;_9`u r ;\T`u r$bZ8;W`ur bVgC;S`u rurbQ FbPz'"bN;bMr+bK3;I `3;F$`MbD&'bC8u rbA$y>;;`u r ;8`$%b7f(;4`?b2urb1y ,tX" *r+4 ( %G $` "A !F  uX r4/ mur5 u r# C 4u r 22 xF Fu prX  )>Q\VAccess controls (2nd edition)4shortly.In order for this style of access control to be effective, it is necessary for the server to be able todetermine that an individual's name actually represents that individual. This is the purpose of thepassword. The name and password together serve to authenticate the individualthat is, to identifythe user and to verify his authenticity by requiring him to provide some piece of information thatonly he knows.It should be clear why it is vital that users choose passwords with care and keep them secret. In anaccess control list based protection system, access is granted solely on the basis of who the requestoris, and not on criteria such as the requestor's physical location, ability to supply a password for theinformation being accessed, or other credentials that the user might possess. An individual's nameand password is intended to represent that individual and nobody else.2.2. Individual names and authenticationIn the Xerox Research Internet, an individual is identified by a Grapevine registered name or R-Name'' composed of two parts, a simple name and a registry, separated by a period. A registry is alogical grouping of names, usually on a geographical or organizational basis; and a simple nameidentifies a specific individual within the registry. Examples of R-Names are Smith.PA'' andJones.EOS''. A complete R-Name uniquely identifies one individual. In the Xerox 8000-series products,R-Names are composed of three parts instead of two, but otherwise are organized essentially the same.The Grapevine servers maintain, for each individual, a password and various other attributes. Oneof the services provided by Grapevine is to authenticate an R-Name and password.When a user requests service from, for example, a file server, that server first demands that the user(or client program acting on his behalf) provide a valid R-Name and password, which it asksGrapevine to authenticate. This process of logging in'' serves solely to identify the user; by itself itconfers no access rights. That is why any authenticated user is permitted to log in'' to any IFS.Control over the user's access to information is accomplished by an entirely separate mechanism.2.3. Groups and access controlGrapevine also maintains groups. A group, to first order, is simply a list of R-Names. A groupitself is identified by an R-Name (which customarily, though not necessarily, contains a ^''character).Groups are used as access control lists, as well as for other purposes such as directing thedistribution of messages. If a group is attached to some piece of information as its access controllist, then an individual can access that information only if his R-Name is included in the group.This is the fundamental basis for access control in IFS, as well as in Grapevine itself.Groups can contain other groups; this capability can be used to model organizational hierarchies,project membership, and various other structures. By using an appropriate group name for accesscontrol, information may be made available to every member of an organization, project, etc., eventhough the actual membership of that organization or project changes over time.Groups can also contain patterns such as *.PA''; any individual whose R-Name matches the patternis considered a member of the group. This facility is provided as an administrative convenience indefining all-encompassing groups (and avoiding the need for exhaustive enumeration); but it doeshave certain consequences that will be discussed later.Permission to change the membership of a group is itself controlled by access control lists. Somegroups may be changed only by duly authorized managers of the organizations or projects whichthey represent. Other groups (the so-called interest lists'') permit any individual to add or removehis own R-Name. frXG b _9!F ] urA \1ur+u r ZC Y) VDO TEu S<r Y QH P4&ur L{uX( IrKur H u rur) FL E 5* CEq B%e ?dr U =P :X 9w8# 7K 6oS 4 T 12uX .Mrur; ,V +E (`N &U %XZ #X I kU W cO ~ur' ` vF 7  \ 6' V  :?QZaAccess controls (2nd edition)5The way this works is as follows. Each group has two access control lists called the Owners andFriends lists. An individual whose R-Name is in the Owners list is permitted to change themembership of the group arbitrarily (as well as to perform certain other operations). An individualwhose R-Name is in the Friends list is permitted only to add or remove his own R-Name in thegroup's membership list. Centrally controlled groups have an empty Friends list, whereas completelyuncontrolled groups have a Friends list of *'', a pattern that matches any R-Name.2.4. IFS file protectionsThe preceding section described the general use of Grapevine groups as access control lists. Theactual use made by IFSs is somewhat more complex.Each file stored on an IFS has a protection consisting of two access control lists; roughly speaking,one controls reading and the other writing. Actually, there is a third list controlling appending, but that is of norelevance to the present discussion. Additionally, each directory on an IFS has a default file protection,which is applied to newly-created files in that directory. Finally, each directory also has two accesscontrol lists that control permission to create new files in the directory and to connect to thedirectory for the purpose of performing owner-like operations such as changing the access controllists themselves.The group R-Names that may be mentioned in these access control lists are limited to a relativelysmall set that is chosen by the IFS's administrator. Thus it is the administrator's responsibility toensure that only suitable groups are used as access control lists.Each IFS also has a special access control list called World'' which represents some all-encompassing user group. For IFSs in the U.S., World'' is usually defined to beUSRegistries^.internet, which consists of all registered Xerox employees and affiliates in the U.S.The intent of this arrangement is that World'' be included in the access control lists of all files thatare proprietary but are not in a more restricted classification (such as private or registered) and haveno other reason for more limited access. This facilitates communication among Xerox employees.Foreign nationals located outside the U.S. (whether or not they are Xerox affiliates) and all non-affiliates are denied access to such files in conformance with the information security requirementspresented in section 1.3. IFS and Grapevine administrative policiesIn this section we describe specific IFS and Grapevine administrative policies that are intended toensure that the information security requirements are fulfulled. Note that these policies must beapplied consciously by the administrators; they are not enforced automatically by the software.3.1. Registry membershipEach Grapevine registry is typically maintained by a single person or a small group of specially-designated people. The registry maintainer has the responsibility for ensuring that only validindividuals are registered.First of all, it is important to understand that there are two classes of registries: those that containhuman individuals (and groups of individuals) and those that contain other names used for specialpurposes. All of the familiar registries belong to the first class, such as PA, ES, Wbst, etc.Registries in the second class contain individuals that do not represent human users but rathermachines, programs, or processes; for example, the GV and MS registries, used for internal controlover the Grapevine data base, belong to this class. These two classes of registries must not beconfused, for reasons that will become apparent shortly.With this detail behind us, we now state the first principle of Grapevine registry administration: frXG bUur `ur I _Y ]U \K ZT VuX Sr+6 Rh1 O!u r0 MqJ L{&r, JI Is)urur GE Fk CV BD" @~B =*1 <W"X0 :L 7[ 6(u r!uru r 4N 3 U 1E 0 +tX, (r$? '#G %/0 !uX r S }Y  I a  L  R H ,4 8 <& ?Q[;_Access controls (2nd edition)6Z 1.Every individual R-Name registered in a normal organizational or geographical registrymust correspond to a human user; and the R-Name is for the exclusive use of that user.This rules out assigning individual R-Names for guest'' or communal use or for automatic'' accessby programs that have such R-Names compiled into them. (This constitutes a major break with pastpolicy. Situations for which such ficticious R-Names have been assigned in the past may be dealtwith by the procedures described in section 4.)Z 2.Every individual registered in a Xerox U.S. registry must be a U.S. employee or U.S.affiliate (i.e., a member of group 1 in the classification presented earlier) or a temporaryvisa employee or affiliate (group 4).That is, every individual in registries such as PA, ES, and Wbst must be a U.S. Xerox employee oraffiliate, or a Xerox foreign employee or affiliate working in the U.S. Non-affiliates and foreignaffiliates must be segregated into separate registries. For example, there exist registries RX and FXcontaining members of the Rank Xerox and Fuji Xerox organizations. It is straightforward to createnew registries for other categories of individuals.The reason for this is that the registries themselves constitute groups whose names are the patterns*.PA'', *.ES'', etc; all individuals in these registries are members of their respective groups. Thegroup USRegistries^.internet is defined in terms of these registry groups; its present composition is:*.DLOS, *.EOS, *.ES, *.Henr, *.LB, *.PA, *.STHQ, *.Wbst, *.XRCC. Since this is intended todescribe all U.S. Xerox employees and affiliates, it is clear that individuals who are not U.S. Xeroxemployees or affiliates must not be assigned to these registries.3.2. Group classificationThere are three basic classes of Grapevine groups, characterized by their style of use:1.Organization groups, which reflect the corporation's organizational hierarchy. Eachindividual who is a Xerox employee is ordinarily a member of exactly one organizationgroup corresponding to that individual's immediate organization. That group is in turna member of some larger group; and this structure continues up to the root of thehierarchy. An organization group may be modified only by administrators associatedwith the organization, to reflect new hires, terminations, and transfers.2.Project groups, composed of members of individual projects. These frequently cutacross organizational boundaries, and may have a hierarchical structure of their own.The membership of a project group is ordinarily controlled by the manager of thatproject.3.Interest groups, which are ad-hoc collections of individuals who are interested in sharinginformation about some subject. The access controls on interest groups are generallyarranged so that any individual can add or delete his own R-Name.The distinction between project and interest groups is not always clear-cut. A good guideline is toassume that any group whose membership is centrally controlled by one or a small number ofresponsible individuals is a project group; all other groups are interest groups. Equivalently, anygroup whose Friends'' list is non-empty or whose Owners'' list is itself a group is probably aninterest group.With this classification in mind, we now continue with the registry administration policies.Z 3.Do not permit interest groups to be used for IFS access control.That is, an IFS administrator should not specify an interest group as one of the groups usable foraccess control on the IFS. This should be obvious: a group to which any individual can add hisown R-Name is a totally ineffective basis for access control. frXG bvr?`(. ]M \101 Z?" Y)/ VDvr6TMS<% PW^ N): MOI KJ JG3 Gbd E@) DZB$ B"9 AR41 ?A <uX 90rWy6K44<3C@1M0;8.Iy+&+*N%0(6'Fy$a!9"6!YA t:* ? lM T d \ vr> <& 2_ =v g>Q[aAccess controls (2nd edition)7Z 4.On U.S. IFSs, do not permit groups containing non-affiliates or non-resident foreignaffiliates to be used for IFS access control, except by prior authorization. Exceptions tothis rule must be approved by the International Deputy (see section 5.1).This is required to ensure that such individuals cannot gain access to information in violation of thesecurity guidelines. Exceptions to this policy for specific projects and individuals may be authorizedby the International Deputy on a case-by-case basis.3.3. International information transferUnder U.S. Government regulations, most transfers of information to foreign nationals (whetherXerox affiliates or non-affiliates) are required to be logged. Since no automatic logging mechanismspresently exist in the Xerox Research Internet, such transfers cannot be permitted via the Grapevineand IFS access controls. Instead, some more centralized and restricted procedures are required.Note that this requirement applies to technical and business documents, but not to casualinterpersonal correspondence conducted via electronic mail. The latter corresponds to first-classletters in the postal system, which are also not subject to any regulations. Of course, the distinctionbetween a document'' and a letter'' is not clear-cut; the sender must exercise some judgement indetermining whether it is appropriate to send a particular piece of information by electronic mail.To ensure the necessary control, it is required that information transfers from U.S. organizations toforeign affiliates be coordinated by the Export Control Coordinator for the originator's organization.This will also ensure that the required records are maintained.The mechanism for transfer is that dedicated IFS directories be established that are accessible forwriting by the Export Control Coordinator and for retrieving by persons in the registries establishedfor foreign affiliates (or preferably by the Technical Information Center of the foreign affiliate,which will then distribute the documents further as appropriate). The Export Control Coordinatorwill determine whether the file is cleared for transmission to the foreign affiliates, move the file tothe dedicated directories, and log the transfer.3.4. Temporary visa employees and affiliatesWhen a foreign national who is working in the U.S. under a temporary visa starts work as a part ofa Xerox group, his Xerox manager must write a memo to his Export Control Coordinator,identifying the employee, his term of employment, and the categories of technical information towhich he will have access (e.g., technical information relating to office information systems, Star,9700, printing). This memo is intended to satisfy the requirements for a documented record of thetechnologies that have been transferred to foreign nationals. The category may be made as broad asis necessary to enable the employee to work effectively and without obstruction. The memo shouldcarry the approvals appropriate for authorizing transfer of information to foreign subsidiaries, and acopy should be sent to the International Deputy.The temporary visa employee or affiliate must also execute a non-disclosure agreement with Xerox atthe time he starts work with his Xerox group. He must do this even if he has previously executedsuch an agreement with a Xerox foreign affiliate.When a temporary visa employee or affiliate leaves the U.S. while remaining an employee orconsultant of Xerox Corporation or an affiliate, his status immediately reverts to the foreign affiliateclassification. In particular, he may not take technical data out of the U.S. unless it has been logged,recorded, and approved in accordance with our export control regulations; he may no longer begranted the broad access available to temporary visa employees or affiliates; and he may no longerbe included in U.S. registries or in U.S. organization or project groups except with specific approvalby the International Deputy. If the employee leaves the U.S. and ceases to be employed by Xeroxor an affiliate, his status reverts to the foreign non-affiliate classification and he may have access onlyto public domain information. frXG bvr@`=_I \1G ZU Y)4 UpuX' RrC QH OV MG K/* IS HX FI E M B%O @K ?? <8F :G 90M 7F 6(;, 40 0uX, .r:( ,= *` ){*: 'b &sR $&; #jJ !0  V }I 1 !9 ^  E$ G 4.  X $< x&E u rr ?Q[^lAccess controls (2nd edition)84. Commonly-occurring problemsIn this section we consider various situations that have arisen in the past and that have sometimesbeen handled in ways that violate the above policies. Historically such practices developed becausethe authentication and access control mechanisms were inadequate. Now that the Grapevinefacilities are available, these practices are no longer necessary and should be abolished.4.1. Communal R-NamesSometimes R-Names are assigned for communal use by multiple people. Strictly speaking, this doesnot result in violation of any information security requirements so long as all users of the communalR-Name have exactly the same status (i.e., are members of the same organization and projects).But there are many disadvantages to this. When no single user is personally accountable for use ofthe R-Name, it's hard to detect and control unauthorized use. When one of the users transfers outof the project or leaves Xerox, maintaining the R-Name's integrity requires changing its password,which inconveniences all the other users (with the consequence that the password usually doesn't getchanged). It's hard enough for administrators to keep track of organization and project membershipwithout having to worry about informal groups'' of users who share a single R-Name.For these reasons, the policy of assigning an individual R-Name to each user should be rigidlyadhered to. If a person has legitimate reason to use the Xerox Research Internet, then that personshould be registeredwithout exception.4.2. Institutional R-NamesA related case is the one in which an R-Name represents not a particular person but some function,organization, or service; the R-Name is assigned for the convenience of people attempting to accessthe entity it represents, so they need not remember the R-Names of the individuals who actuallyembody that entity. Examples of such R-Names are LaurelSupport.PA and NetSupport.Wbst.In this situation it is usually most appropriate for the R-Name to identify a group instead of anindividual. The members of the group are simply the R-Names of the people representing thenamed entity.Sometimes institutional R-Names have been registered simply so that messages can be sent on behalfof those institutions. However, this is not necessary, since Laurel permits the originator to specifythe From'' and Reply-to'' fields of a message explicitly; for example, a member of theLaurelSupport group can compose a message that says it is From: LaurelSupport.PA''. In this case,Laurel adds a Sender'' field to identify the actual originator of the message.4.3. Delegated accessSometimes a user will desire to delegate access or authority to another person. For example, a usermay want his secretary to read his mail while he is on vacation, or may want to make some privatefile available to a second person. Users sometimes give out their passwords to others under suchcircumstances.This is never appropriate, and always violates the information security requirements. It should beimpressed upon users that they are to keep passwords secret and never divulge them for any reasonwhatever.An individual's incoming mail may be temporarily diverted simply by establishing a forwarding''entry for that individual in Grapevine.In general, users should be encouraged to work within the system when transferring information toothers. If some individual does not have access to certain information, it is usually because theindividual is not a member of some group that he should be in, or because the information's access frXG bt _9rF ]R \1K ZZ VuX Tr/2 RU QS N##@ L^ K/3 Id H6- FU CV B%.5 @' ;&  C ' 2@! 3/ *:( >Q](KAccess controls (2nd edition)9control list (file protection) has been set incorrectly. Smooth information transfer requires thatpeople understand how the protection system works and how to use it.4.4. Automatic accessA number of programs have been developed that access IFSs using a compiled-in R-Name andpassword instead of the credentials of the human user running the program; examples of such R-Names are Guest, ARUser, Librarian, and Smalltalk-User. The existence of such R-Namesconstitutes a security loophole, for reasons already presented, and they must be abolished.Most uses of compiled-in credentials exist for no better reason than that the implementors of thesoftware consider it too inconvenient to obtain the human user's credentials. Users are justifiablyannoyed when they must log in repeatedly because the software they are running forgets theircredentials in mid-session (e.g., because a new Pilot volume is booted); alleviating this annoyance isa likely reason for the widespread use of compiled-in credentials. But the resulting adverse impacton information security makes this practice no longer tolerable.In a relatively small number of cases, such automatic'' access really is required because humaninteraction is impossible for some reason. For such applications, it is possible to establish individualR-Names representing non-human entities; but these R-Names must be in special registries that donot also include human individuals. That is, it is unacceptable for such R-Names to be in registriessuch as PA, ES, and Wbst. (For example, the existing RS and MS registries contain R-Namesrepresenting the individual Grapevine registration and mail servers.) A special registry, Auto'', hasbeen created specifically for this purpose; to register an individual in the Auto registry, send amessage to Registrar.Auto.Access by such non-human individuals to information must then be precisely controlled by properdefinition of groups and use of access control lists. Such individuals are not in any IFS's World''group since their registry is not among the ones included in USRegistries^.internet; thus theircredentials cannot be used to subvert the protections of proprietary information.System implementors who elect to adopt this strategy should be aware that all informationobtainable by such automatic'' means may also be accessed by anyone able to obtain a copy of thesoftware (or discover the R-Name and password by other means), regardless of who or where he is,whether or not he is a Xerox employee, etc.To summarize: a program accessing information on behalf of some human user must obtain andpresent that user's credentialswithout exception. Only when human interaction is impossible (e.g.,in servers that run unattended) should credentials be compiled into programs or otherwise stored forlater automatic use; but such R-Names must be in special registries (e.g., Auto) which are notincluded in USRegistries^.internet.5. Additional information5.1. PeopleHorace Becker (8*222*2163) is the International Deputy for Reprographics and Jerry Elkind(8*923*4610) is the International Deputy for Non-Reprographics. Each organization has its ownExport Control Coordinator.5.2. DocumentationMore detailed information about electronic information security and proper use of the authenticationand access control facilities is available from several sources: frXG bE `D \uX Yr M Xx^ VI Up[ R U Q(< OV M X L{U J@ HL FH! E : ur CQ BG @~M >b =v :=" 9 N 7T 6Q 3 I 1?ur 000 .+ +0* *+3u r (d '#^ %# !tX Zu ur L @ m uX rd L@ D >QY0Access controls (2nd edition)101.Electronic information security guidelines'', in the October 1981 issue of the XeroxResearch Internet Newsletter.2.IFS meets Grapevine'', in the March 1982 issue of the Xerox Research InternetNewsletter.3.How to use IFS'', filed as HowToUse.press on many file servers.4.Maintain reference manual'', filed as Maintain.press on many file servers. frXG?yb>`y]0\1 yYLFyVg> V 8@ TIMESROMAN  TIMESROMAN TIMESROMAN LOGO TIMESROMAN  TIMESROMAN MATH  ! + 5 @ J SUj/X V(AccessControls.bravoTaft.PAAugust 24, 1982 4:37 PM