high-level security architectures and the kerberos system

201

Networking Technology

High-level Security Architectures and the Kerberos System *

Denis RUSSELL Computing Laboratory, University of Newcastle upon Tyne, Claremont Road, Newcastle upon Tyne, UK NE1 7RU (Tel.: + 44 91 222 8243; Fax: + 44 91 222 8232; E-mail: Denis.Rus- [email protected])

Abstract. The U K academic communi ty is concerned about network security. This paper reports some of the findings of the first stage of a study of network security. There is an assessment of the major networking threats to the communi ty ' s comput ing activities, an outline of the activity and prospects in the relevant standards areas, and a description of the Kerberos system from MIT.

Finally, there are some tentative conclusions that indicate that s tandards activity will probably not deliver a timely solution and that an interim solution involving the widespread use of Kerberos in the U K communi ty is the most desirable short to intermediate term solution. However, there will still be problems to solve for the U K community, and some of them are indicated. An appendix provides an outline of security technology.

Keywords. Network security, open systems, key management , Kerberos.

Denis Russell gained a B.Sc. and a Ph.D. in the Physics department of Newcastle University, and spent two years doing geophysics research in Canada. Returning to Newcastle, he moved to the Comput ing Laboratory and has been involved in the computing service for 20 years. In the 1970s he was instrumental in establishing the Nune t network across Newcastle and Durham. He spent a year with the networking team at the University of Michigan in the early 1980s. Recently,

his main area of interest has been distributed processing, and authentication, security, resource control, and accounting have been the primary focus of attention. In 1989 he published a book on networking. * This paper is based on a report submitted to the U K Joint

Networking Team as part of a study contract.

North-Holland Computer Networks and ISDN Systems 19 (1990) 201-214

1. Introduction

Like many other groups, the UK Academic Community is increasingly worried about computer security. At its annual Networkshop particular concern has been expressed for several years concerning the insecurity of Ethernet. The worries about networking security have culminated in the commissioning of two studies of the problem. One by Steve Wilbur will be concerned with the particular problems of computer mail. The other, by Denis Russell, is charged with the general high- level security issues. This study will produce two reports. The first, which forms the basis of this paper, sets the scene by summarising the perceived threat, assessing the status and prospects of relevant standards activities, and examining the Kerberos system from MIT. There will be a second report that builds on the first to suggest a short-term plan of action for the UK community. This study is viewed as complementary to the study of electronic mail, and there is collaboration between the two efforts.

2. TheMofivafion

The UK academic community is experiencing several changes which are simultaneously causing it to consider security measures. Examples of hacking and viruses attract the most publicity, but potential threats such as eavesdropping on Ethernet are causing much alarm too. Eavesdrop- ping can result in passwords being compromised and in any other transmitted information being disclosed unintentionally. Less obvious, but perhaps as important is password guessing.

The eavesdropping threat may be countered by suitable strong authentication methods. Such

Elsevier Science Publishers B.V. (North-Holland)

202 D. Russell / High-level security architectures

schemes protect against eavesdropping by the use of cryptographic techniques. However, many such methods are still ultimately based upon passwords that users must remember, and there is still a large advantage in encouraging high quality passwords.

The threat of disclosure of confidential data to eavesdroppers is clearly important for some kinds of service. It has been suggested that all Ethernet data should be protected from disclosure by encryption. However, this is clearly impractical at present. Apart from the cost of such a crash program, the standards and technology are just not available. In addition the average editor of a FORTRAN program or a report such as this, or the recipient of a voluminous mailing list that is disseminated worldwide is unlikely to welcome the cost of such security services. It is clear that selective confidentiality services are required as and when the need is perceived.

Systems with strong authentication that allow users the freedom to share facilities without sharing computer identities (and thus passwords) improve overall system security. A sharp distinction must be made between doing this in conjunction with strong authentication and systems that dispense with weak authentication and rely on even weaker host authent ica t ion-- resul t ing in a hacker's delight.

Any solution that is proposed must take into account the particular aspects of the community's activities including the widespread interworking between Universities, the frequent use of simple terminals attached to PADs, and the importance of hosts for which no system modifications may be performed.

3. Standards

The most desirable solution to our problems would be to appeal to international security standards. If these would counter all the threats we perceive and would allow open access for valid users with minimal disruption, and if such standards could be specified in procurements, be af- fordable, and be available in short order, then this would obviously be the way to go. The major effort in this part of the study has involved an assessment of the present status of the international security standards effort, and this is sum- marized in this section.

This section assumes a basic familiarity with the capabilities of encryption-based technology. It also assumes that most of the discussion takes place in terms not of "encryption" but in terms of the abstract security services that can be built from the basic technology. The appendix contains a fairly extensive sketch of the relationship between the basic encryption technology and the services discussed in this section.

There is much security activity in the standards area. Unfortunately, most of the ISO structure has grown up in the absence of a proper security model. Until fairly recently, security mostly con- sisted of offering an identity and an authenticating password. There has been little serious thought about the dangers of eavesdroppers stealing passwords or of observing traffic passing by. The result is that many standards contain little more than a place-holder for a password, and any security facilities that there are are ad-hoc and incon- sistent across various applications.

This situation is now changing. The ISO security architecture ISO 7498-2 was finalized in 1989. A lot of work has been done within ECMA in refining and extending this architecture, and in fitting it into the rest of the architecture.

3.1. The I S O architecture

ISO 7498-2 is entitled "Security Architecture". Perhaps the biggest achievements of this document are the way in which issues are teased apart and then decisions are made concerning where specific services are made available. More specifi- cally, the various services that a user might require such as authentication or confidentiality are defined quite separately from the mechanisms by which such services might be implemented (quite independently of the fact that these services might be implemented by cryptographic or physical means or by means as yet undefined). It is expected that future standards will define ways in which specific services will be implemented. Fur- ther, specific communities of users will be expected to form specific "security policies" that depend in a complex manner on their own circumstances and expectations. Security policies are fairly high-level sets of rules and aims that are designed to achieve the kind of security that is deemed necessary. It is expected that these policies will be implemented in part by choosing

D. Russell / High-level security architectures 203

specific security services from those provided by the standards process, and that these security services will in turn be achieved by choosing suitable standards that implement these services.

For example, a security policy may specify that all network users must be authenticated by strong methods, that all network traffic must be protected from tampering, and that some network traffic must be prevented from disclosure to eavesdroppers. This might be implemented by choosing suitable authentication services for all users, integrity services for use at all times, and suitable confidentiality services for use when appropriate. In turn these services would be implemented by choosing the appropriate set of authentication, integrity and confidentiality standards.

3.2. The Main Security Services

In this section we shall proceed to outline the primary services that are defined in ISO 7498-2. We shall give some brief indication of how each might be defined in terms of the underlying encryption technology outlined in the appendix. However, the reader should be aware that this indication is for illustration only and that there may be several other ways of achieving the same service. In addition, we shall simplify the set of services somewhat. For example, the standard mentions the three services "Connection Con- fidentiality", "Connectionless Confidentiality", and "Selective Field Confidentiality" while we shall treat all these together.

3.2.1. Authentication This is the corroboration that the peer entity or

data origin in question is as claimed. Traditionally, this has involved the presentation

of a password--a shared secret--as the corroboration. However, poorly chosen passwords are easy to guess, and passwords passed " in the clear" are easy to steal. Thus this is now considered a "weak" method of authentication. Strong methods of authentication involve the use of the password as an encryption key in a more complicated exchange. This makes the simple "grabbing" of the password impossible. In addition, the stronger methods of authentication make it much more difficult to guess passwords by careful design of the authentication protocol. Some protocols tend to use a concept called the "Privilege Attribute

Certificate" (or PAC-- th i s concept is used more generally than just in authentication). This is an unforgable binary pattern that can only be used by the rightful owner. In the Kerberos system there is the closely parallel concept of a "Ticket". Other methods of authentication involve the use of one-time passwords or challenge and response systems.

Weak passwords are notoriously easy to guess. There are various schemes to improve the quality of passwords. Encouraging users to avoid single words (by having a dictionary of forbidden passwords) and easily obtainable personal information, to include special symbols (but not their telephone number!), change their passwords from time to time and so on are useful. Unfortunately many methods defeat their purpose by forcing unmemorable passwords on users that inevitably get written down and are thus physically insecure. Short of this extreme, a combination of education and sensible measures can achieve much.

3.2.2. Access Control Service This is the limitation of access to that set of

entities that is properly authorized. Typically such a service is implemented in a time-sharing system by having an "Access L i s t " - - a list of those entities which have authorized access. In a label-based system each resource and each entity have a label such as "Secret", "Top Secret", etc, and only when there is a suitable match between the labels of the resource and accessing entity is the access allowed.

Access control clearly requires suitably authenticated identities for all the entities involved.

3.2.3. Confidentiality This is the property that information is not

made available or disclosed to unauthorized entities.

Traditionally this is the classic application of cryptography. The information is passed between two communicating entities suitably encrypted using secure keys. However, other ways of achieving confidentiality are by controlling the route taken by the traffic so that it cannot be inter- cepted, or by controlling the transmission medium so that it is difficult to eavesdrop. The use of fibre optics is said to make unauthorized tapping very difficult. The most secure military networks use


this kind of approach in combination with cryptography.

Traffic flow confidentiality is difficult to achieve on an open network. At the very lowest level, encryption below the framing on a point-to- point link could obscure traffic flow from an eavesdropper. However, this kind of protection has very limited application. On an open network, traffic flow can only really be hidden by sending rubbish when there is no "real data" to send. However this nullifies one of the main reasons for having a shared network. If traffic flow confidentiality is required, then it must probably be achieved by means of the control of routing and eavesdropping by non-cryptographic means as ex- plained above.

3.2.4. Data Integrity This is the property that data has not been

altered or destroyed in an unauthorized manner. One way of achieving this is to calculate a

digest of the piece of data in question, and then pass that digest in a secure manner. Typically this is achieved by passing the data in the clear, but sending the digest under cryptographic protection. The recipient can compare the (small) digest with the (larger) piece of data to detect alteration. This service can be provided either as the detection of tampering only, or together with some automatic recovery service to attempt to retrieve the original unsullied piece of data. As discussed earlier, integrity and digital signatures are closely related.

3.2.5. Non-repudiation Repudiation is the denial by one of the entities

involved in a communication of having par- ticipated in all or part of the communication.

Non-repudiation comes in two flavours. "With proof of origin" involves supplying the recipient of the data with proof of the origin of the data, and "with proof of delivery" supplies the sender with proof of delivery of the data.

Non-repudiation is normally discussed in terms of mail messages where the sender and receiver may not be active at the same time. There is an implication of non-repudiation of both origin and delivery with, say, a properly authenticated interactive session. However, the terminology and service are more suited to the exchange of a mail message or a data file particularly when some kind of long-term contractual arrangement is involved

and the electronic exchanges are replacing traditional document exchanges.

Non-repudiation with proof of origin is usually considered to be implemented with some kind of digital s ignature- -of ten involving public-key cryptography. Non-repudiation of delivery is rather more complicated. One scenario is that the document is delivered to the recipient's user agent and a suitable receipt, signed digitally, is returned to the sender. It is then assumed that the recipient will access the user agent and personally retrieve the message.

The complication arises in designing a service that insists on proof of delivery even of messages (like a summons) that a recipient might wish to repudiate immediately The task is to design a digital receipt that is sent before the message itself can be read.

Public-key signatures sometimes involve the use of a trusted time-stamping service as a way of resisting fraudulent disavowal. As an alternative to the use of asymmetric cryptography for signing messages, the transaction of issuing, authenticating the origin, receiving, or issuing a receipt could be registered with a notary service. There are several possible levels of notary service involving various trade-offs.

3.3. Placement of Services

In addition to defining the security services as outlined above, ISO 7498-2 also makes various choices about where in the protocol tower the services may and may not be made available. In fact, there is a great freedom of choice still available in the model. In addition, the model says very little about how the actual services in any one layer will be implemented. Until these matters are resolved by the appearance of other standards the possibility exists for any service to be provided either by the use of services provided by the lower layers, or by using an additional peer-entity to peer-entity protocol, or by some as yet undis- covered means.

3. 4. Present and Future Work

The date of ISO 7498-2 is 15th February 1989. Presently work is progressing to elabcLate the architecture and produce service and protocol definitions for the whole architecture. However, such


work is at a fairly early stage. One of the important inputs to this is the work being done in ECMA. ECMA T R / 4 6 was an important influence on the basic architecture, and later ECMA documents, in particular " D a t a Elements and Service Def in i t i ons" - -TR/138 (the whimsically named "Alice in Wonderland" document) can be expected to influence current work.

One of the important concepts is the so-called "Privilege Attribute Certificate" or PAC. The PAC is a piece of data which is protected by cryptographic means that enables the implementation of various security services in a consistent and neat way. The PAC allows the possessor to access facilities on the network. In some ways it acts hke a password, but in contrast to the password it is protected by strong cryptographic means, and allows much more functionality. There is a strong correspondence between the PAC and the Kerberos Ticket.

As we shall see below, the existing set of security services includes a wide variety of pre-7498-2 facilities. At the application level the most desirable aim would be for security facilities to be available to all applications as a security Common Application Service Elements (CASE). In this way, all application level services could use the security CASE and dispense with their own ad-hoc facilities. However, this will not happen soon. Work has not yet even started on a security CASE, and in the meantime services must be provided. As usual the world, i.e. the users, will not wait. In the short term this means that the ad-hoc facilities will even need to be strengthened while the ideal solution is being developed. However, it seems pru- dent that they should be extended in a way that is consistent with the architecture as it is developing. As a specific example of this, the replacement of "password fields", and particularly the semantics implied by that name, by a field into which a PAC or a Kerberos Ticket can be inserted (instead of or alternately with a " tradi t ional" password) would both be a big step in the fight direction, and allow a large improvement in security.

3. 5. A vailabifity of Standardized Protocols

With the recent appearance of the security architecture, it is hardly surprising that there are few

protocols that are conformant with it. Two excep- tions to this are the IEEE 802.10 work on link-level encryption, and the work on SP3 and SP4 security protocols for the network and transport levels. However, even here there are some significant problems. Neither the IEEE work nor the SP3 /4 work specifies any key management. This is a proper division of function, but the problem is that there is no key management yet in the ISO framework that could be used.

In the meantime recourse is made to "Ne twork Management". There are two problems with this. One is that it merely puts the vital question of key management to one side rather than anything being done about it. The other is that key management must be done in a secure way. Doing anything securely involves, preferably, trusting as fit- tie as possible. If the whole of the large and growing "network management" structure needs to be trusted, then the security of the resulting system will be low.

Quite apart from issues of key management there are still technical and other difficulties with the SP3/4 protocols and their interaction with other protocols at levels 3 and 4.

Authentication exchanges are the subject of several ongoing ISO standardization efforts. These are elaborating the details of the various kinds of authentication exchange that can take place de- pending on the use of symmetric or asymmetric technology and the use of authentication servers. However they are still some way away from specifying the details of an implementable protocol.

The Security Framework for Open Systems is a seven part standard:

1. overview, 2. authentication framework, 3. access control framework, 4. non-repudiation framework, 5. integrity framework, 6. confidentiality framework, 7. audit framework.

Of these only the authentication framework has reached the status of Committee Draft. The access control is getting a lot of revision, and no little disagreement among the contributors, and the other documents are technically deficient and not very active. In addition there is a new work item on key management. However it is not clear that there will be sufficient resources internationally to


enable good progress with this vitally important item.

It has been said that the area of key management seems to lend itself to solutions that appear to be proprietary. If this really is the case then the prospect for secure open systems looks bleak.

One other area where there has been much ISO standardization is that of Electronic mail. The details of this effort are the subject of a separate study, and so we shall not look at it in any detail. This standardization corresponds with similar efforts that have taken place on the Internet (RFCs 1113, 1114, and 1115). In addition in the directory service (X.509) there are facilities for weak authentication (storing and comparing passwords) and strong authentication (the provision for the storage and retrieval of the public component of asymmetric key pairs suitably certified).

It is not clear how well this structure agrees with the architecture in ISO 7498-2. However, it will probably be widely implemented independently of any agreement. Since a key management system is specified as part of this setup, it would be good if any system used for interactive access and FTAM could be the same. However, this may not be achievable if a fundamentally different scheme is used for these non-mail services.

Several other protocols, in particular FTAM, do have some security features. These are usually not consistent with the security architecture since they were introduced before that architecture was properly developed. These features are currently being revised because in their present form they compromise the security of systems that are other- wise highly rated.

At the May 1990 ISO meeting in Seoul it was decided that the place-holder for a password in the FTAM protocol should be generalized to a "b i t bucket". The point of this is that, as mentioned above, a Ticket (in the Kerberos sense) or a PAC could be used in place of a real password.

3.6. Standardization Prospects

There is a long way to go before the architecture results in a set of ISO protocol and functional standards that may be specified in procurements, and even longer before these result in an in- tegrated secure networking environment consistent with a security policy suitable for a Univer- sity. It has been estimated that it may be five to

seven years before a suitable set of implementable standards exists.

In addition, the academic community presents a unique challenge in that it is part of a worldwide open community with no central funding or organization, nor even ultimate authority. World- wide interworking is state of the art on a gigantic scale and the free exchange of information is an article of faith. And yet at the same time there is a large supply of highly skilled, intelligent and motivated attackers within our community with a variety of motivations for attack. Most commer- cial or government enterprises will have quite different requirements, and this may well mean that security services appropriate for the academic community are not at the top of the list of priori- ties for the manufacturers.

3. 7. The P L U S Decision

In the USA the defence community is critically dependent on the integrity and availability of digital data. A final report into security pertaining to "Protection of Logistics Unclassif ied/Sensit ive Systems" (PLUS) on 30th October 1989 recommended that Public Key Encryption (i.e. asymmetric encryption) combined with the use of DES should be used for the protection of unclassified data, and that they should proceed with some prototype demonstrations based on facilities from RSA Inc.

4. Kerberos

Kerberos is an authentication system that is part of project Athena at MIT. The system has been well documented elsewhere, particularly in the Winter USENIX 1988 in Dallas.

In broad terms, Kerberos provides an authentication service that works fairly closely like the Needham and Schroeder authentication model. That is, there is a trusted authentication server and users wishing to authenticate themselves to services enter into a dialogue with the authentication server that is protected by cryptographic means using symmetric-key technology. Each user has a network-wide identity rather than a machine-specific identity. (In fact, though we refer to users and services, Kerberos makes no such de- stinction between its various clients.)


The exchange involves the user obtaining a "Ticket" which is a certain kind of cryptographi- cally protected certificate fairly similar in general concept to the privilege attribute certificate that is widely used in ECMA standardization efforts. The ticket essentially proves the identity of the possessor, and allows the further use of the distributed system of services for a period typically of several hours. This allows the user to " log in" once for a "session", and then continue to use a variety of services without the need for repeatedly entering new passwords for each new service used.

It would appear that, subject to such restric- tions as character set and length, a Kerberos ticket (or an ECMA PAC) could replace the password in various protocols, such as FTP, and thus allow much improved security with minimal impact on the protocol.

The user and the service are mutual ly authenticated (and thus rogue servers may not masquerade and compromise users). In addition to authenticating the users and services to each other, the Kerberos service also generates new "session" keys. These are cryptographic keys that may be used to encrypt data and thus provide such security services as non-disclosure.

The Kerberos service may be duplicated across several actual machines to improve availability in the face of machine failures. The simplicity of the Kerberos database enables a particularly simple kind of maintenance across the duplicated servers.

Each Kerberos server authenticates users in a "domain" or "realm". There are facilities for several Kerberos servers to interact across realm boundaries to implement cross-realm authentication. However, it is not clear how such cross-realm interaction scales, and further investigation of this would be required before the wholesale implementation of a set of interacting servers across the whole of the community could be recommended.

The Kerberos system includes a library of routines that may be called to implement the various aspects of the service. Various applications are "kerberized" by the suitable use of various calls to this library to achieve the desired effect. The effect of this for the user is normally minimal.

There is significantly more to the Kerberos service than this simplistic explanation implies.

Kerberos is designed to fit into a network of workstations each running Unix. The human user will be physically using one of the workstations.

(Some of) the encryption that is necessarily a part of such an authentication system will take place inside this machine. The machine is the user's agent or sponsor within the distributed system.

The implication of this is that Kerberos does not directly address the question of authenticating users of simple terminals on PAD lines. However there has been some recent discussion concerning the integration of the Kerberos system with authentication via "hand-held authenticators" (i.e. portable or pocket computers with a limited pro- grammable capability).

The current Kerberos lives in a networking world where the communications medium is T C P / I P . The protocol data units are carried on top of the TCP data stream. The only dependence upon the T C P / I P protocol suite is that a network (i.e. l / P ) address is included as part of some of the PDUs in order to make certain kinds of attack more difficult. This version of Kerberos mandates the use of either DES or a closely similar encryption algorithm.

A new version of Kerberos (version 5) contains similar but extended functionality. Some of the more important alterations that have been made are that the specific encryption algorithm is an option. It can be DES, or it can also be almost any other symmetric algorithm (though clearly which one must be agreed). In addition many of the protocol messages have ASN.1 coding, and there are wide options on the content of various fields, especially the network address field.

In addition to the authentication and optional confidentiality services implemented by the earlier version of Kerberos, version 5 also defines an integrity service.

It would appear that either version of Kerberos could work on either a T C P / I P stack or an ISO stack. It may be that at least version 5 could work in a mixed environment.

Kerberos is rapidly being adopted by many manufacturers. The latest movement is the adoption of Kerberos (version 5) by the OSF.

In the USA Kerberos is freely available across the Internet via anonymous FTP. However, there is some restriction on the export of security-related "devices" from the USA, and it appears that this forbids the export of the system from the USA despite its free availability there. A version of Kerberos without the library of encryption routines (that could fairly easily be re-imple-


mented) was also produced. The exportability status of this version has been somewhat uncertain but it appears now to be available. There are complete versions of Kerberos operating within the UK. The wide uptake of Kerberos by vendors must result in some movement of this rather strange situation.

5. Tentative Conclusions

From the survey of the situation as detailed in the previous sections, it is clear that authentication services plus at least occasional confidentiality services are urgently required by the UK Academic community. International standardization will produce an excellent set of security standards in due course. However, the realistic prospects for this must be at least five years in the future, with even longer before products implementing them are widely available from vendors.

There is a range of desirable solutions.

1. Adopt suitable ISO security CASE services as they are defined and become available, together with a suitable key management service.

2. Adopt an interim key management service, and use the keys or PACs that it produces in place of the password fields in current protocols.

3. Adopt an interim key management service, and use the security services that come with it. (The implication being that only the accompanying protocol stacks would be supported.)

The most desirable of these solutions is 1. How- ever, we have seen that the time scales indicated are towards the end of the decade. Solution 3 could be pursued by adopting Kerberos "as is". This would give added security, but primarily for Unix services on t h e T C P / I P suite. Solution 2 could be pursued by first adopting Kerberos as under solution 3, and then "migrating" by implementing the protocols on top of ISO stacks, and progressively replacing the use of passwords in various protocols by PACs. This is in line with interim changes that are being made to ISO protocols, for example to FTAM.

The attributes of Kerberos, coupled with its wide adoption by Unix suppliers in particular must mean that the only pragmatic progression is in the reverse order of solutions: 3, 2, 1. Experi- ence with this course of action, coupled with con-

tinued participation in the standards process, should ensure the most rapid route to the availability and adoption of suitable ISO standards. Just waiting for the ideal standard solution is the counsel of despair, and not participating actively in the standards process against a background of real experience seems a good way of ensuring that the process is unlikely to yield an ideal result.

There do remain problems even in adopting a "ready" solution like Kerberos. Apart from the export problem, there are the services in the community that may be difficult to cover with Kerberos. In particular, these are dumb terminals on PADs, non-Unix services in general, and " turn-key" hosts in particular--especially finan- cial and administrative systems. There is the question of retaining access from "non-Kerberized" sources without compromising security. There are questions about the scaleability of a Kerberos system should it be applied nationwide to the U K community.

These and other questions will be considered in the second stage of the study.

Appendix. Outline of Security Technology

This appendix outlines the available security technology. It is not a tutorial, but it does try to outline the ways in which the technology of security is built upon the foundations of encryption. For details of the protocols and algorithms the reader must refer to suitable publications.

Virtually all security in the ISO standards world is built on encryption technology. This appendix summarizes the major results from encryption and indicates how they are used to build security services. This appendix is not exhaustive. For example it does not cover some of the most recent papers on authentication using one way functions, nor does it cover Chaum's ideas on security without identification. This is not a judgement on the value of such ideas (actually I think they are excellent) but rather a judgement of what is relevant in understanding and evaluating existing standards work.

A. 1. Encryption

The fundamental notion of encryption is that a message is transformed by some process (encryp-


tion) that makes it unintelligible to anyone who cannot perform the complementary decryption process. In mathematical notation, if the original message (plaintext) is P, and the encryption process is represented by the function E{}, then the encrypted message (cyphertext) C is expressed by

C = E { P } .

If the decryption process is represented by D{ }, then

P=D{C} = D ( E { P } ) .

Modern encryption goes further in that both the encryption process and the decryption process consist of a method or algorithm and an associ- ated key. If we express the use of the key as an extra parameter on the encryption function, then

C=E{P, K¢) and P=D(C, Kd}

where K e and K d are the keys used for encryption and decryption. It is assumed that the algorithm itself cannot easily be changed and will not remain secret, but that the keys can be comparatively easily changed. The strength of the method relies on the design of the encryption function and the secrecy of the key. Indeed, publishing the encryption algorithm for public scrutiny is a powerful way of testing the strength of its design.

"Tradit ionally" the two keys K e and K d were either identical or easily derivable, one from the other. In 1975 asymmetric encryption was introduced in which the two keys were quite different (but related mathematically). Indeed, K e can be "published", and any member "of the public" can use K e and the corresponding well-known algorithm to encrypt a message to produce C, but only the possessor of the secret K d can use the decryption process to produce the original plaintext. This is often known as "public-key encryption" after the ability to publish one of the keys as well as the algorithm, though the term "asymmetric encryption" leads to less confusion when dis- cussing protocols. This has lead to the corresponding term of "symmetric" encryption for the more traditional form of encryption.

Symmetric and asymmetric encryption have related but different properties. With symmetric encryption, cyphertext can only be read (decrypted to produce plaintext) by someone in possession of the secret key. An "enemy" observing the com-

munication cannot read the message. Conversely, if a message is decrypted and results in an intelli- gible message, then only a possessor of the secret key could have produced the message and thus the message is "authentic".

There are caveats concerning this point. If the expected plaintext has no redundancy or structure, then applying the decryption process to any bag of bits instead of genuine cyphertext will produce another bag of bits which is as eligible as any other to be a message. Only if there is sufficient redundancy to distinguish valid plaintext from the general set of random bits can this test be success- fully applied. Most representations of text or communications protocol messages contain sufficient redundancy for this test to be applied.

The second caveat concerns "freshness" or "replay". If a message on a communications medium is recorded by an enemy and later replayed, then despite the fact that the enemy could not read or alter the message, the message will arrive out of sequence, be decrypted by the receiver, and recog- nized as a valid message. This kind of attack by replay is primarily a spoiling tactic, though it can be used to compromise some authentication protocols in certain circumstances. Fortunately it is fairly easily thwarted by adding a time-stamp, sequence number, or random number that is later checked.

With asymmetric encryption, the situation is similar, but with some subtle differences. When a message is encrypted using the public key, then only the possessor of the private key can decrypt the message. Thus the method provides a "m an y to one" secret channel. However, since the public key is by definition widely known, then anyone can have performed the encryption and there is thus no parallel with the authentication provided by symmetric encryption.

However, some asymmetric algorithms have the property that if the possessor of the secret key applies the "decryption" process to a message, then the subsequent application of the "encryption" process results in the original message. In mathematical notation,

P = E { D { P } } .

[The terms "encryption" and "decryption" are slightly misleading here. All they really imply is the application of the algorithm and the ap-


propriate (public or private) key to one "bag of bits" to produce another "bag of bits".]

The point about the message D{ P } produced by the holder of the secret key is that anyone can, by using the public key, obtain the original plaintext. However only the possessor of the private key could have produced the message. (A similar caveat about plaintext "making sense" also applies here.) Thus, using asymmetric encryption in this mode provides a one-to-many authentication channel.

Another way of looking at this "one to many" authentication channel is to refer to the message D ( P } as a "signed message". Just as the human signature on a paper document authenticates the document for any reader, so the fact that D{ P } can be verified as authentic by any possessor of the public key effectively "signs" the message. Moreover, the normal way of encrypting a message ensures that any tampering with the authenticated message invalidates at least a large part of the message. Thus the signature not only authenticates the origin of the message, but also protects or "seals" it against tampering. This is the basis of the "integrity" services.

(We shall see below how the use of a digest function results in a small signature much more like the traditional writing or seal attached to the message rather than as a property of the whole message.)

A "certificate" is a message that is digitally signed and sealed as authentic. Usually a certificate contains some further security-related information, such as permission to access an object or resource.

Thus, to summarize, symmetric encryption with a shared secret key provides a one-to-one secret or confidential channel together with one-to-one authentication. Asymmetric encryption with the public key widely known and the private key secret to one person provides a many-to-one confidential channel, but no authentication. If the algorithm is capable of being used in the inverse way described above, then a one-to-many authentication channel is also provided.

Note that the properties of each encryption method rely on the correct distribution of and trust in the keys. In the symmetric case the one key is shared between and secret to the two communicating entities. In the asymmetric case, the private key is known only to the one entity, and

the public key is widely and reliably available. Making sure the keys and their association with the intended entities are authentic, reliable, up- to-date and secret is the subject of "key management". Proper key management is a complex process which lies at the heart of computer encryption technology.

A.2. Message Digests

One last building block is the "message digest func t ion" , "one -way func t ion" , or " h a s h function". A message digest is the result of applying the message digest function to a message of arbitrary s ize--f rom a few characters up to a whole computer file. The digest itself is fairly short, perhaps 8 or 16 bytes long, and anyone can calculate the digest (there is no secret key involved). However the digest has various properties - principally that it is infeasible to produce two messages with the same digest (though in principle there will be many "large" messages for each "small" digest, finding them is computationally infeasible). This property means that if you are sure of the authenticity of the digest of a message, then you can be similarly sure of the authenticity of the message to which the digest corresponds.

Message digests are often used as part of a digital signature process. We have observed that the message D ( P } is verifiable by a suitable application of the appropriate public key. This process is less than perfect, and a superior method is to form a digest of the message, and sign ("decrypt") only that. Thus, if G is the digest of a message P, then D { G } forms the new signature. There are several advantages of this method. One is that the message P is sent in the clear, and is thus accessible without necessarily checking the signature (it may be sufficient to check the signature only occasionally for example). Another advantage is that the protection against tampering is easier to check (instead of the woolly test "does the message make sense" the precise test "does the digest of the whole message agree with what I get by looking at the signature" can be used). Again, several signatures can be suffixed to the one message. There are other advantages too.

A.3. Algorithms

A proper treatment of the subject of specific encryption algorithms and hash functions is out-


side the scope of this paper. However we need to make some brief comments. This area is very active and extremely mathematical. The most widely known symmetric encryption algorithm is the ANSI Data Encryption Standard (DES). This has been in the public domain for well over ten years and is widely used for non-classified security. DES specifies a 56-bit key. Despite much work, there is no published method of "attacking" DES that is significantly better than trying all possible keys and thus it would seem that DES is a suitable algorithm to use.

Should DES be compromised, then there are various other symmetric algorithms that could be used to replace it.

One problem with DES is that it is a bit-oriented algorithm designed with hardware implementation in mind. Software implementations tend to be fairly expensive in computer resources. However, Merkle has devised a similar algorithm that is designed to run in software and is thus much faster ( = less expensive in terms of computer resources). In addition it is designed to be more secure. After a suitable period of public examination this may be the algorithm of choice for software implementations.

With asymmetric encryption, only one widely discussed algorithm has stood the test of time. This is the so-called RSA (Rivest, Shamir, Adel- man) algorithm. Other long-standing algorithms, such as the knapsack algorithm have been broken, and none of the more recently proposed algorithms has had sufficiently long public scrutiny for there to be widespread public confidence in them. The RSA algorithm depends essentially on the difficulty of factorizing the product of two large prime numbers. This is a long-standing problem in mathematics that has withstood many years of effort by mathematicians. With the interest in cryptography in recent years there has been significant effort in this area. The result of this is that certain constraints have been placed upon the choice of the primes involved, and the "safe length" of the prime numbers has been consider- ably increased.

However, the problem has not mathematically been proved to be "hard" , and according to the state of our knowledge it is quite possible that an efficient algorithm could be found.

The probability of this happening is impossible to estimate.

Should this happen, there is no other well tested, generally available algorithm available to use in the place of RSA, and all asymmetric technology would be in search of a replacement algorithm.

With message digests, there are several algorithms that are receiving public scrutiny, but it is not yet clear whether any has yet been sufficiently tested that it can with confidence be specified in a standard. This situation should soon change.

A.4. The Subject Sponsor

In a system where security is implemented by cryptographic means the human user must have a computational sponsor of some kind to perform the cryptographic functions on her behalf. Whether this machine is a smart card that the user carries around, a private machine in the user's office, or a shared machine in a public area, it must be trusted by the user for the duration of the protected interactions. Since the user is here a "Security Subject", the sponsor is sometimes referred to as a "Subject Sponsor". The notion is somewhat similar to a "User Agent" in mailing systems, and the two may well be combined in some implementations.

A.5. High-Level vs Low-level Encryption

Voydock and Kent (1983) analyzed the implica- tions of security mechanisms in an open systems environment. They looked at the two extremes of "Link-Oriented" and "End- to-End" measures.

In gross terms, link-oriented measures secure individual links in a network. Encryption will normally be done in hardware because of the perfor- mance required (though in the author's experience experts disagree on the feasibility of performing encryption at raw network speeds even in hardware, and whether the hardware is actually widely available). If the encryption is performed immediately above the data encoding level but below the packet framing level, then even the frame structure and thus the traffic pattern will be obscured (because even framing and idle states will be obscured by the encryption) . However, on a shared network such as a LAN or MAN the framing and at least the M/X C addressing cannot be obscured, and so some of the traffic pattern will be discernable by an eavesdropper. (In princi-

212 1). Russell / High-level security architectures

pie they could be obscured if every LAN or MAN station shared the same key. However, it is difficult to see the utility or security of a system that involves a "secret" that is so widely shared.)

Link-Level encryption would protect against unauthorized eavesdropping on the link. However, such protection would not extend to the data within all other intermediate systems, including network switches, and thus a large class of threats concerned with the vulnerabilities of these intermediate components would not be countered. However, if the encryption could be performed in hardware, it would come extremely cheaply, and thus be an effective way of countering this specific kind of threat. The highest security networks use link-level encryption in addition to host-level encryption.

On the other hand End-to-End measures protect against many threats to all intermediate components, including eavesdropping and network switches. There is discretion about where to place the "ends", and the closer they are placed to the communicating entities, the less intermediate components need to be trusted. This is a powerful argument for installing security measures at the very highest level in the ISO protocol tower--preferably in the application layer itself. Of course, at whatever protocol level a security service is implemented, the implication is that the protocol of all the lower levels will not be protected (at least by this mechanism). This means that any information that can be derived from the routing, session, traffic, or syntax of the lower levels will not be protected. In addition, the higher the level at which encryption is implemented, the less the chance that hardware encryption devices may be exploited, and thus the corresponding greater cost there will be in software encryption.

These worries aside, many observers believe that most encryption protection should be done either at the highest or at the lowest levels, and that only unusually is protection at an intermediate level appropriate.

This study is explicitly concerned with high- level security measures.

A.6. Key Management

Modern encryption depends for its security on suitably well-proven encryption algorithms and the availability of suitable keys. The algorithms

themselves are not secret, and are often standardized and widely implemented. For effective use, communicating entities must have appropriate keys available. For symmetric encryption, two parties should normally share a key which is secret to themselves and unknown to anyone else. For asymmetric encryption each party needs to know the public key of the other, and each party's private key should be secret to itself alone. How- ever, there are problems in achieving this state. Usually these problems are solved by using a key distribution service of some sort. The service works differently for symmetric and asymmetric encryption, and we shall outline the two separately.

A. 6.1. Symmetric Key Servers If two entities are to communicate using sym-

metric key encryption, then the two entities need to come into possession of a shared secret - - the encryption key. For a small number of entities, "out-of-band signalling" can suffice. In this method, each entity obtains the secret key it will use for every other entity by some secure means independent of the insecure network. One such method is administrat ive--a user talks to an ad- ministrator of some sort, establishes her identity, and obtains a key for use with each possible service or entity. This is the traditional model for obtaining passwords for a (small) number of time-sharing services. Since the number of preal- located keys that must be obtained by such out- of-band means increases as the square of this number of entities it rapidly gets out of hand. Many of us are familiar with the way in which multiple identities on multiple machines rapidly result in unmanageable password problems.

Needham and Schroeder examined this problem in 1977 and presented a particular solution. This is based on the concept of a trusted authentication server. In their model, each entity shares a single identity and key with a single, trusted, network-wide authentication server. When one client entity, A, wishes to communicate with any other server entity, B, it communicates securely with the authentication server (using its single key). The authentication generates a new (random) session key, and distributes this securely both to the client A and the server B using their secret keys. This process results in A and B authenticating themselves to each other without either learning the other's private key, but by virtue of both trusting


the authentication server. The mutual trust between .4 and B is thus limited to the one interaction, though the authentication server is implicitly trusted for all interactions by all entities.

The basic authentication protocol has been elaborated to protect it against certain kinds of attack, and also to make it more suitable for service in the Kerberos system, but the basic no- tions remain the same. In the basic model, all entities share (trust in) one server. However, the model is easily extended to cover multiple servers each with a single domain, perhaps with a hierarchy of authentication servers to enable simple inter-domain authentication.

.4.6.2. Asymmetric Encryption Needham and Schroeder also examined the cor-

responding protocols for asymmetric encryption. They found that for single authentication interactions the number of messages was the same for both asymmetric and symmetric encryption, and there is apparently no advantage in using asymmetric encryption. This is surprising, since asymmetric encryption had the simplification of key distribution as one of its main goals.

In Needham and Schroeder's model, the extra complication was the perceived need for mutual authentication between the client and the authentication server, and this gave rise to the number of messages. However, it has been pointed out that with asymmetric encryption the key serving process can be arranged in an hierarchy with a master public key authenticating lower-level certificates which contain the public keys of lower-level servers. The initial master key upon which the lower-level keys depend can be distributed by various secure means outside the basic model (special courier or multiple "tradit ional" publication have been suggested), and this infrequently needed event does not contribute to the message count. Moreover, since the servers only contain the public keys and even the certifying authority need never know the private keys, then the overall security of the system contains fewer trusted elements, and those elements require less trust than with symmetric key technology.

Clearly a direct comparison is difficult and rests on the evaluation of risks of differing kinds. This is particularly true when the extra complica- tions of notary and time-stamping services that we shall meet presently have to be considered. Both

kinds of technology currently have their adher- ents.

Asymmetric encryption algorithms are much more expensive in computational resources than symmetric algorithms. For this reason, asymmetric encryption is often used in conjunction with symmetric encryption with the expensive asymmetric encryption being used as a way of achieving mutual authentication and establishing a shared session key. The session key is then used with the cheaper symmetric algorithms to maintain security services during the session itself. Typically, RSA technology is used for authentication and the establishment of the session key, and DES technology is used during the session. This combination is the basis of the PLUS recommendation mentioned in section 3.7.

A. 7. The Notary Service

We have seen how encryption keys can be distributed and perhaps created by means of a key service. This service needs to be trusted by both parties in a transaction in the case of symmetric encryption.

A similar service that is sometimes considered is a "Nota ry Service". This, like the symmetric key server, is a trusted third party, but rather than being directly involved in authentication it is used to register transactions.

The idea is that rather than certifying a piece of data by signing it with the private component of an asymmetric pair of keys, the piece of data is "registered" in a secure way with the notary service. Extra information, such as the date of the transaction and so forth may also be registered. At a later time any (other) entity can ask the Notary Service for verification that the piece of data is authentic. A notary service based on symmetric- key technology would have to keep some audit record of the transaction. However, this could in principle be as little as a digest of the transaction. A notary service using asymmetric key technology need not keep such an audit trail as long as its private key remained uncompromized. However, an audit trail would still increase confidence in the reliability of its service.

This corresponds closely with the use of the public part of the asymmetric pair of keys to check the validity of the certificate. The interactions with the notary service can be made secure

214 1). Russell / High-level security architectures

by any suitable means, physical security, human intervention, or whatever, though encryption of some kind is the most likely.

There are of course, two important differences between using digital signatures based on asymmetric encryption and verification using a notary. The first is that the dependence upon asymmetric encryption technology is replaced by a reliance on a notary system, and the second is that the possibility of keeping an audit trail in the notary system makes dishonest repudiation that much more difficult.

To expand on the second point, it has been pointed out that a digital signature using asymmetric encryption may be repudiated by deliberately compromising the corresponding private key. From that time on all the relevant digital signatures are worthless--their validity lasts only as long as the secret key of the issuer is not compromised. However, if the verification is by means of a notary service, then the dishonest revocation of the transaction involves not just deliberately compromising any encryption keys now, but also convincing the judicial authorities that the keys involved at the time were compromised. This would be, practically, much more difficult.

To counter this threat of dishonesty on the part of the message originator, the use of a (trusted) time-stamping service has been proposed ( I S O / lEG JTC 1 / S C 21 /WG1 $35). A message is signed by the issuer, and time stamped and re- certified (including especially the issuer's signature) by a trusted time stamping service. At any later time, subject to the integrity of the time- stamping service's key, the time of the signature can be verified. Such a verification would make dishonest repudiation that much more difficult. In addition, there are various possible flavours of time stamping service, with the simplest asymmetric key certification just described with no audit trail, or with audit trails retained by the server. With those varieties that rely on audit trails, symmetric encryption can also be used.

Of course, the use of either a notary service or a time-stamping service also involves implementing such a service and operating it in such a way that it is trusted by its customers and any judicial authorities involved.

The use of a notary or a time-stamping service to authenticate large transactions, such as issuing a long message, does not necessarily involve the presentation or storage of the whole of the message. In just the same way that message digests are used to form certificates, the digests corresponding to any message or transaction may be registered with a notary. In this way the notary does not even have to be trusted with the knowledge of the transaction to which the digest corresponds-- i t only has to be trusted with the storage and re- verification of the digests themselves. However, if the whole message or transaction is presented to a notary service, then the transaction record can contain a secret digest or even the whole transaction. Clearly there is yet another complex tradeoff between the added security involved by presenting only a digest to the server and presenting the whole message and allowing the server to produce its own secret form of digest as a record.

References

[1] T.M.A. Lomas, L. Gong, J.H. Saltzer, and R.M. Need- ham, Reducing risks from poorly chosen keys, in: Proc. 12th ACM Symposium on Operating System Principles (1989).

[2] M. Merritt and S. Bellovin, Limitations of the Kerberos authentication system, Comput. Comm. Rev. to appear.

[3] ECMA TR-46, Security in open systems - A security framework, Available from ECMA, 114 Rue du Rhone, CH-1204 Generva, Switzerland.

[4] ECMA TR-138, Security in open systems - Data elements and service definitions, Available from ECMA, 114 Rue du Rhone, CH-1204 Geneva, Switzerland.

[5] V. Hempei, Final report - Protection of logistics unclas- sifted/sensitive systems (PLUS) Voi. 1, Office of the Secretary of Defense Production of Logistics, Systems Department of Defense, 1989.

[6] S.P. MiUen, C. Norman, J.I. Schiller and J.H. Saltzer, Kerberos authentication and authorization system, Project Athena Technical Plan, Section E.2.1, MIT, 1987.

[7] D.M. Russell, the principles of computer networking, Cambridge, 1979.

[8] W. Diffie, The first ten years of public-key cryptography, Proc. 1EEE 76 (5) (1988).

[9] V.L. Voydock and S.T. Kent, Security mechanisms in high-level network protocols, Comput. Surveys 15 (2) (1983).

[10] R.M. Needham and M.D. Schroeder, Using encryption for authentication in large networks of computers, Comm. ACM. 21 (12) (1978).

high-level security architectures and the kerberos system

Documents