💾 Archived View for dfdn.info › reading › authentication.gmi captured on 2024-06-16 at 13:05:55. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
Network Authentication Issues
Editor: C.J Cheney (University of Cambridge Computing Service)
Date: 20 January 1998 [URLs revised 21 April 1998]
Summary and recommendations
Authentication is the process of validating that computer or network users are who they claim to be and that they are authorized to use the facility. Authentication is normally carried out by a password-checking mechanism [1]. Password checking gives an adequate level of confidence in the authentication for the academic environment at present; it is likely that more sophisticated schemes, e.g. based on smart cards, will become practical in the not too distant future.
Authentication attempts, whether successful or not, should be logged as this enables the system administrators to answer the question 'who was using or apparently attempting to use the computer/network from a specified location at a specified time'; it is important to be able to answer this question in dealing with internal or external (e.g. police) enquiries about hacking incidents.
The following recommendations are proposed to enable a period of transition to be initiated as early as possible; this transition upgrades the existing network to one which is better protected against casual misuse.
Institutions should audit and upgrade security of existing networks and should plan new or upgraded network installations, as far as is reasonably practicable, in accordance with these recommendations.
Computer systems should require authentication of the user before access to the CUDN/JANET is allowed. However, computers in, for example, offices where there is sufficient security to prevent unauthorized use do not need authenticated logon. 'Sufficient security' should be interpreted taking relevant factors into consideration, e.g. shared offices and access by cleaners.
Authentication attempts should be logged, whether the attempt is successful or not, and the log should be kept for a minimum of a month. These logs should not be readable by users [2].
Remote login [3] on a computer system should be authenticated and logged [4] unless the originating system can be trusted to have already done so. Computer systems which provide facilities for allowing onward network calls should run an RFC1413 ident service, or a similar process on Netware systems. Managers of these systems should also run regular scans for well known network access doors [5] which may have been left open whether accidentally by incautious or inexpert users, or maliciously.
Networked computers with particularly insecure operating systems should not be made available in general-use areas without adequate supervision; for example a demonstrator should be present whilst the systems are in use.
Wiring closets and similar locations housing active network equipment should be physically secure.
Active network outlets in general-use areas should be connected via a managed security hub which should be configured to prevent the attachment of unauthorized equipment.
Unprotected active network outlets should not be accessible in open-access areas.
General-use areas such as classrooms and laboratories which contain networked computer systems which do not otherwise comply with these recommendations should be accessible only by key or similar security mechanisms except at times when they are actively supervised.
Issues of funding for the above are not within the brief of the IT Syndicate Technical Committee. The IT Syndicate may, however, wish to consider the funding issues and make recommendations.
Introduction
Following its commissioned report Technologies to support Authentication in Higher Education [6] from Young, Kirsten and Ibbetson, the Joint Information Systems Committee of the HEFCs (JISC), which manages the funding for and is responsible for JANET, has announced in JISC News, no. 1, Spring 1997, [7] that it 'is undertaking a feasibility study into the provision of a JANET-wide authentication system' and that 'an assessment of the technical issues and costs is required before progressing and the ACN [the JISC's Advisory Committee for Networking] has commissioned two papers to assist in this process.' One paper [8] is concerned with security measures for the WWW and the second [9] is to address the technical and practical details of the implementation of security services across JANET. The ATHENS authentication system [10] is now being used to provide controlled access to subscription services provided by publishers and data suppliers and made available via the Data Service Providers (DSPs) NISS, BIDS, EDINA and MIDAS. Many of these services are offered to the education community on the basis of CHEST agreements.
It seems reasonable to expect that an authentication policy and the implementation of a JANET-wide authentication system would be likely to converge to a state whereby all network users accessing JANET had to be authenticated so that, e.g.
random people cannot come off the street into an open-access computer room and gain access to JANET, and
if there is a case of JANET network abuse, then there is some chance of identifying the perpetrator.
Such authentication would be no bad thing and would help to protect the University and the Colleges against network abuse by both their members and third parties.
However, there is considerable concern, at least in some HEIs, about the practicality of such a policy and on its implications on the availability and use of IT facilities within the institution. It is clear that a policy whose implications were that personal computers running applications such as Word, Excel, compilers, web browsers, etc. could not be networked would be totally unacceptable.
Level of user expertise
The ITS-TC considered that absolute guarantees of authentication were impracticable given the current state and deployment of IT facilities. However, the committee believed that the provision of some level of authentication is desirable. It considered that it would not be worthwhile to try to plug all the 'features' that an expert computer user could make use of, but ensuring that a knowledgeable user [11] who is not an expert is authenticated would be sensible.
Environment of the computer
In the case of a personal computer, being for the sole use of a particular person and being located in an appropriately secure place, e.g. an office which is locked when not occupied, formal 'logon' authentication is not considered to be necessary as the person can be deemed to be responsible for all use of that computer. However, consideration should be given to possible use of the computer or the network access point by unauthorized persons who might have legitimate access to the room, e.g. cleaners, and therefore logon authentication might be desirable.
In the case of a personal computer in an open-access area, e.g. one of Cambridge's Public Workstation Facility (PWF) computers or similar computers in departments and colleges, logon authentication is most desirable, whether or not it is a formal requirement for connection to JANET.
Operating systems
For a modern IBM-compatible PC, it is generally possible to password-protect the BIOS setup and to prevent booting from a floppy disk; therefore it is possible to ensure pretty strictly that the machine can only be booted over the network and, therefore, only after an authenticated logon. This is so because the network-card boot-ROM code is executed during the BIOS initialisation, i.e. before control is passed to code which is loaded from a vulnerable source (e.g. the hard or floppy disk). However, it should be noted that BIOS passwords are vulnerable as there are several programs readily available which can read the BIOS password from the CMOS RAM (and possibly decrypt it, if it is encrypted) - of course, prior authentication is required to get to a state where such a program can be run. It is also very easy to open up a PC's case (there are generally only 4 screws to be undone) and to discharge or disconnect the battery which is keeping the CMOS memory, in which the BIOS password and the basic configuration are stored, alive - physical precautions, such as loop alarms, can be used to discourage such attacks.
Logon authentication can be enforced for Windows NT. This is because the Windows NT file system, NTFS, is secure, i.e. users cannot gain direct access to the hard disk.
Windows 95 cannot, in practice, be booted from the network in a secure manner comparable with the same operation with MS-DOS/Windows 3.1 nor is the hard disk file system secure as is the case for Windows NT. Whether the level of expertise needed to circumvent logon authentication using Windows 95 is beyond the capability of a knowledgeable but non-expert user is a matter for debate.
Similarly Macintoshes cannot be booted from the network and, although the file system may be more secure than that of MS-DOS and Windows 95, it is believed that authentication measures can be evaded without difficulty.
Unix systems in general and, in particular, Linux systems do not in themselves present a problem. If it can be guaranteed that the system booted is the uncorrupted system intended by the administrator, then the ordinary user can be authenticated and constrained adequately.
It should be noted that personal computers which are configured with multi-boot capability are, of course only as secure as the least secure operating system which can be booted.
Considerable expertise is needed to configure systems sensibly, whatever the operating system. One cannot, in general, expect the average institutional computer officer to be sufficiently expert in all operating systems and network technologies. The institution that wishes to run multiple operating systems should be prepared to employ an adequate number of staff to configure and maintain these systems; in addition, the Computing Service will, of course, be able to provide expertise and advice for institutional computer officers.
Firewalls
A firewall cooperating with an authentication server could be used to prevent traffic from systems being used by unauthenticated users. This might be possible now for certain systems and further study is required to determine the current state of the art in this area.
Firewalls can also be used to prevent or, at least, limit various other forms of network abuse, e.g. IP spoofing (one machine masquerading as another by forging its IP address).
Physical security
Although it is generally accepted that no special security measures over and above normal wiring practices are needed for the physical network in HEI environments, consideration must be given to unprotected network outlets because of the availability of portable computers. In the case of a building which has been flood-wired with UTP, it would be prudent to ensure that unused network points are not patched to active network equipment in the (secure) wiring closet.
Further protection can be achieved by using managed secure hubs: these learn the MAC addresses of the attached devices and will block traffic on the appropriate port if those addresses change - the port can then only be re-enabled by management action. Devices which ensure that more complex address/protocol mappings are enforced are also available, but at a higher cost than secure hubs.
Systems which can alter their MAC addresses will cause problems for secure hubs. Whilst such activities were commonplace in the past with DECnet systems, this is unlikely to be a great problem these days, unless it is done maliciously.
Timescale considerations
The introduction of authentication requirements needs adequate notice and planning, especially considering the supposed impossibility of doing this for certain operating systems. The amount of work and the amount of funding needed to implement a moderate level of security together with authentication across the institutions of the University and the Colleges are such that a period of transition will be necessary.
Open-access systems
At present, access to the CUDN and to JANET may not be provided to those who are not staff or students of the University and its Colleges, except for certain exceptions [12]. Certain institutions wish to provide open-access information systems so that anyone who happens to be there is able to access certain information over the network; a particular example might be an open-access computer in the Scientific Periodicals Library used to access the University Library's catalogue system - it would be inconvenient to prevent outsiders, who might have been afforded legitimate access to the SPL, using this computer. In some cases, the temporary visitor clause would apply, but this could not be used for a long-term visitor. However, it would be feasible for the institution to hold a number of JANET Proxy Connection licences and then, subject to the agreement of the IT Syndicate, the individual's agreement to comply with the conditions of use for JANET and the CUDN, and a signed indemnity, network access which was limited to information browsing could be provided. Alternatively, the IT Syndicate might approve unauthenticated access for specified systems within the University as long as it was not then possible to access systems outside the CUDN. This issue is for further study.
[1] Other mechanisms are acceptable, e.g. for a computer whose use is directly supervised, signing in (pen on paper), with a check on the identity of the person against a driving licence or similar, would be considered to be adequate.
[2] Because one of the most common log-in failures is where a user erroneously responds to the User: prompt with their password.
[3] Or more specifically, any access that directly or indirectly allows unconstrained command execution.
[4] The program tcpwrappers is the accepted standard, platform-independent tool for Unix systems.
[5] The classic and all too common problem is a .rhosts file designed to make access easy for the authorised user but which also makes access easy for anyone else.