Authentication services


Authentication is the process of establishing that a real world subject is the identifier it claims to be. An identity can be proven by:

Something you know, eg. a password

Something you have, eg. a smartcard, a challenge response mechanism, a public key certificate

Something you are, eg. positive photo identification, fingerprints, biometric devices

Authentication should be secure. It is the atomic service that enables all activities in the networked world. Authentication should be accessible to any application that wants to use the service. A single sign-on, to the extent possible, has real benefits to both users and the overall IT environment. Authentication should be efficient; it should not tax the resources of either the system or the user. Authentication should be effective. Applications should not have to be customized to use alternative authentication schemes.



Universities typically authenticate their primary electronic identity - an account on a host - using passwords. Frequently that network transaction is in clear text, allowing for sniffing of passwords and resulting security compromises. Many applications and resources have separate authentication services.

A significant number of schools use Kerberos as an authentication tool. Kerberos has the advantages of encrypting passwords and enabling some degree of single login. This can be done using unix based ids as the principal id. DCE and Windows 2000 (nee NT5.0) uses a form of Kerberos as well. There are other schemes, such as SSH, that can encrypt passwords, but do not provide single logon as well. Digital certificates may also be used as an authentication option. However, use of certificates requires campuses to provide all the rest of the services that comprise a public key infrastructure. For a discussion of these issues , please see other material on this web site.

Authentication techniques such as smartcards and biometric devices are rapidly developing but still immature. They incur significant expense with specialized hardware needed at each keyboard. (Although some new smartcards can be plugged directly into USB ports.)

Among the many resources and services that require authentication is the directory. At the same time, the directory can be the repository for much authentication information, including digital certificates and passwords. This intimate relationship between directories and authentication necessitates a coordinated development of the two services.

It is possible to use several different forms of authentication, such as both passwords and smartcards, to verify against a specific identifier. In fact, some schools have implemented such utilities that use a Kerberos authentication process to fetch digital certificate forms of authentication (and vice versa). It is also possible to use a particular form of authentication to establish one of several identifiers a real world subject might have, such as carrying multiple certificates on a single smartcard.


Next Steps

Establishing a campus-wide authentication infrastructure requires a mix of policy and technology. It is dependent upon wide-spread agreement of issues about both identifiers and levels of acceptable risk, as well as existent campus approaches and technologies. Hence there is a need to begin with processes in identifiers and risk management. Information elsewhere on this site describes an approach to developing campus agreement on identifiers. Risk management itself is a complicated subject, involving understanding of the nature of exposures and consequences of compromises as well as the costs of implementing varying levels of security. As the amount and value of on-line resources increases, so does the risk.

At the same time, there are a set of best practices that a campus should consider in designing its authentication services. Attachment 1 contains some of those guidelines. Many more will be added in the next few months.


The following are some of the many references for Kerberos

The higher ed community in England shares a very extensive authentication system. Information is available at


Appendix 1 - Assessing the campus authentication environment

Does your campus have a centralized authentication service?

Do you sync passwords among several authentication systems?

(eg Kerberos, NT, Netware)

Do you check passwords for non-crackability?

Do users have to change their passwords regularly?

If/when you observe compromised passwords (eg from a cracker's sniffer

log) do you invalidate the user's account? What procedure does a user

follow to get their account reinstated?

Do you have policy about the use of the central ID/authentication system by

applications, eg, central admin systems must use these IDs?