- Email: [email protected]
Authentication in a heterogeneous environment
Authentication Environment
in a Heterogeneous
June M. Power and Steve R. Wilbur Department of Computer Science, Gower Street, London WCIE 6BT
University
1. Introduction
College London,
This paper considers how a mechanism might be set up to provide authentication of users and servers. The scheme proposed aims to deal with simple processors which are unmanaged, as well as managed timesharing systems. It would provide authentication tokens which can be included in the applications protocols. Much of the difficulty of the scheme is concerned with building a distributed secure database for private keys. Keywords: Authentication, Protection, Security, Distributed systems
June Power’s first degree was an A.B. in Computer Science from the University of California at Berkeley. She has been a resident in the U.K. since 1979 and received an M.Sc. in Computer Science from University College London in 1983. Since then she has been a research student at the same college, specialising in the area of Protection in Distributed Systems.
In a distributed system clients on one machine may access services on another. Even if management arranges that the coded user identification (uid) is identical on both (all) machines, passing such uids in unencrypted messages may lead to penetration of important resources by unauthorised third parties. There are several forms of attack which can be made on network based systems: Eavesdropping: listening to conversations which are private and making use of the contents in other transactions. Faking: generating messages or replaying earlier legitimate messages to gain resources for which the faker is not authorised. Trojan Horse: pretending to offer a service, perhaps even offering it, but gathering information which allows impersonation of clients on other servers. Our local distributed system is vulnerable to these attacks, especially faking and the use of Trojan Horses. This paper explores possible solutions.
2. The Environment Steve Wilbur graduated in Electrical Engineering in 1966, and obtained an MSc. in Computer Science in 1968. His early career interests were in computer aided design and operating systems. More recently his research has been concerned with local area networks and distributed systems, leading the University College team in Project Universe. He is now principal investigator of Project Admiral sponsored by the UK Department of Industry as part of its Alvey Programme. Important aspects of these projects are the integration of local and wide-area high speed services and the management of applications and networks spanning several administrations. Particular areas of study include: remote procedure call, naming, security, and distributed system structuring.
North-Holland Computers & Security 6 (1987) 41-48 0167-4048/87/$3.50
The University College London, Department of Computer Science (UCL-CS) environment consists of a number of local area networks (LANS) which are interconnected and have gateways to other external networks. Various service time sharing (Unix) machines are attached to the LANS, as are a variety of communications servers, file servers and microprocessors. At present, various machines authenticate users when they begin a session. However, such authentication only serves one machine, although having been authenticated a uid is often passed between machines by specific applications. Thus, authentication currently may allow terminal access at a given time to machine A, and file transfer to machines B, C, D provided the uid is also valid there, but no terminal access
0 1987, Elsetier Science Publishers B.V. (North-Holland)
-
-. .i, . .~ -
Fig.1.
-
link
-
._,
RING
_
-
MICRO--LAB RING
UNIVERSE
3 68000 Codata workstations *
SUN bridge
:
I t
To
A
MRC ULCC
x.25
act
_
dataqrams X.25
machines
._ ,_,
I
.”
under
I I I
._
KILOSTREAM
To
Area
-
-
run BSD 2.8 (like Version have ethernet connection can be used.
_ _ ,“_
All may 2.9
Local
.._._
/-
possible ethernet connections
Terminal gateways. Handle Network Service system access to UCL and o,,t to PSS, JANET and the ARPA internet.
7 UNIX) (if BSD
Networks
Science
Departmental
Computer
J.M. Power and S.R. Wilbur / Authentication
to B, C, D without further authentication. The file transfer protocol itself is insecure, since users on any of the machines with direct network access could inject messages containing any uid, including the privileged user id. Servers are found by name-to-address mapping in a name table. It is difficult but not impossible to change this table and interpose a fake server (Trojan Horse) between the client and true server. Equally, if a legitimate server moves, and another eventually takes over its old address, the client and possibly the server would like to be aware of this, rather than trying to perform an inappropriate action. Thus, besides having authentication of users, there is a need for authentication of servers too. The environment being considered is shown in Figs. 1 and 2. Mm are managed machines, in that users are authenticated when they begin a terminal session, and that access to the LAN is via a managed kernel. In principle, the kernel could prohibit access to the LAN, and certainly would provide a limited set of modes of access. The unmanaged machines, Mu, do not have any such secure network interface; thus there is no way of, say, preventing such users from listening to all transactions on the LAN or changing the node’s network address if the hardware permits such functions. The server machines, MS, may either fall into the same category as Mm, or may have a kernel which is available in source form to some users, i.e. the kernel may be protected/privileged at run-time to limit faults and share functions, but
in a Heterogeneous
appl icat 10” kernel
R,-
managed
machine
Mu - unmanaged machine MS - server machine Mg -gateway machlne Fig.2.
43
may be changed by the user at development time to include new functions. Finally, the gateway machines, Mg, are generally similar to MS, except they have to impose access control between the LAN and WAN.
3. The Models is currently working on a draft proposal for authentication [l] based largely on the earlier papers by Needham and Schroeder [2] and Israel and Linden [3]. In the ECMA document two forms of authentication are proposed, strong and simple. “Strong” is intended to resist attack, but may impose computational delays at execution time, whereas “ simple” is fast but much weaker. The strong approach uses the DES algorithm for encryption. Needham and Schroeder propose an alternative based on PKC, which is interesting but even more computationally demanding than DES based approaches. PKC will not be considered further in this document, the intention being to see whether the ECMA models are adequate for a heterogeneous environment such as UCL-CS. ECMA
3.1. Simple Model The protocol for the ECMA model is shown below.
simple authentication
A +B: A, Ksa B --, Au: A, Ksa Au-+B: b B-A:
a-
Environment
Ksa
(1)
where A is the name of the initiating client, B is the name of the recipient or server, Au is the authentication service, Ksa is A’s simple key and b is a Boolean variable which indicates whether or not Ksa is A’s simple key. The client sends its name A, key, Ksa, and a transaction request to the server. In turn, the server contacts an authenticator and asks for these to be validated, whereupon a suitable response is returned. Presumably to prevent fake results being returned to A, its key is returned with the results. All messages are in cleartext, i.e. no encryption is used at any point in these transactions. Ksa is private to A, and is also known to the authenticator. Management of keys is not dealt with in the
44
J.M. Power and S.R. Wdbur / Auihentication
ECMA proposal, and as a minimum there needs to be a per session or per transaction exchange of the form:
A +Au:
A, Pwd
Au-A:
Ksa
(2) where Pwd is some token for authenticating A. Clearly any eavesdropper observing the plain text Ksa or Pwd at (1) or (2) can pose as A. This simple approach therefore seems to be most appropriate for distributed systems where access to protocol messages is impossible because of physical security, or where low grade resources are being protected. Another approach would be for the authenticator to be able to generate a sequence of keys, each session or transaction having a different one. The management issues appear to be difficult, since there may be many processes owned by A and also multiple authenticators. Keeping all keys in step even in a perfectly reliable environment would be difficult, but in the face of intermittent loss of messages and re-transmission, it is felt that this scheme needs considerable further study. 3.2. Strong Model The protocol for the ECMA strong model is shown below. It relies on encryption and assumes that all network nodes have a reasonably well synchronised clock. A +Au:
A, B, I
B-A:
Environmen
together with sufficient information to pass the key to B and verify that the message containing the key has not been replayed. The client contacts the authenticator (Au) giving its own name, that of B and a random number called the nonce which will not be used again for a long time, and cannot be predicted. Au then invents a new key, Kc, for the conversation, which it encrypts together with the name of A and an expiry time (several hours away, typically) with B’s private key. It then takes this coded data, the name of B, the nonce, and Kc and encrypts them with A’s private key. Thus, only A can decrypt it and check the nonce. The Kb encrypted data is passed to B, together with the current time of day, XORed with the processor ID of B. The purpose of this is to prevent replay of messages, in that only a small amount of time should have elapsed during the transaction between A and B. The scheme is largely that of Needham and Schroeder, but with expiry time and transmission time included [4,.5]. The inclusion of time poses two problems, namely keeping the clocks of each machine sufficiently synchronised for the scheme to work and making the scheme work in batch or buffered systems as opposed to directly coupled systems.
4. Implementation
Issues
4. I. Protocol Hierarchy
Au + A: [[Kc, Texp, A + B: [Kc, Texp,
m a Heterogeneous
A]Kb,
I, B, Kc] Ka
A] Kb, [Ti XOR PIDb] Kc
[TjXORPIDb]Kc
(3)
where [ ]Ka means that the quantity between the square brackets is encrypted under A’s private key and [ ]Kb and [ ]Kc are equivalent for B’s private key and the conversation key, respectively. A and B are the names of the initiator and recipient, I is a random number called the nonce, Texp is the expiration time for a set of credentials, Ti is a time stamp obtained from the system clock at time i, Tj is a time stamp obtained from the system clock at a later time than Ti and PIDb is the processor ID of B. The authenticator knows the private keys of both the client and server, and when the client asks to be authenticated, a conversation key Kc is returned which can be used to encrypt the data,
Two broad families of protocols have to be authenticated. One is stream protocols, the other is transaction protocols. It is not considered necessary at present to cover threats at the protocol level, and indeed the scheme developed will suffer many of the deficiences outlined by Watson [6]. Thus, the authentication protocol sits above both the stream and transaction protocols. In the case of stream protocols, the stream would be opened in the normal way. Once established, or in parallel, the client will obtain the relevant credentials from the authenticator, unwrap them and pass the conversation key to the server. The server in turn will give a handshake to this message. Both message and handshake will be carried over the newly established stream. Thereafter, all data messages are encrypted as discussed below. Protocol messages are not encrypted, so an
J.M. Power and S.R. Wilbur / Authentication
interloper could inject fake resets or resequence packets. This kind of threat is considered to be acceptable. For transaction protocols, there is an initial session-like binding performed by client to server in the scheme currently in use. At that stage the client asks to be bound to one of several servers for a particular service. This binding mechanism must be extended to include the exchange of credentials which then hold until the binding is terminated. It is possible for a client to be bound to several servers simultaneously. In such cases the conversation keys used should all be unique, so that discovery of one key does not compromise all servers. 4.2. Encryption
Algorithm
Performance
If encryption is to be used, it must not significantly degrade performance. The ECMA proposal suggests use of the Data Encryption Standard (DES) [7] for encryption, but in the U.K. the use of DES encryption chips is tightly controlled. Other encryption algorithms could be used, but they would necessarily prevent interworking with proper implementations. Software based encryption has been considered, and according to Newman [8] software performance of around 2Kbps can be achieved on a 16-bit machine for data blocks of 16 X 8 bytes. Such performance is significantly inferior to that of our stream or transaction protocols and is unacceptable where very short messages are involved. Following Newman’s work our early implementations will use additive stream cipher mode (ASC). In this, a pseudo-random number generator is used to produce 64-bit values which are encrypted by DES in advance, and then xoa-ed with the text as it is being sent or received. Present 16-bit machines can perform such stream ciphering at rates of the order of 100 Kbps. 4.3. Key Storage and Distribution Distributing keys is extremely difficult, and encipherment is useless unless the key management is secure. In terminal systems it may be tempting to have users be responsible for keys. This does not solve the problem, however, as it depends upon the individual’s security system. The problem is being passed to users and they often cannot be trusted!
in a Heterogeneous
Environment
45
We are concerned about the problem of users and therefore find it useful to investigate the storage of keys in the system and their distribution. Not all the systems that we are dealing with have human users interacting with them. Servers may need to be re-booted in the middle of the night and so there is need for an automatic secure key distribution mechanism for such machines. In general we believe this to be an intractable problem. However, one solution which is being pursued is to introduce a security kernel in a front-end processor which is inaccessible to the normal user. Another aspect of the problem is whether the key storage should be centralised or distributed. A centralised approach is attractive from the point of view of management, but it would be unacceptable for such a vital part of the system to become disabled. Thus a distributed and replicated approach is favoured. In many respects the problems of key storage are largely traditional database problems with the added complications of security. 4.4. Time The ECMA standard includes the notion of “Universal Time” (UT), which is held accurately (unspecified but approximately 1 second) in each machine. A time server must be provided to ensure this. The time protocol should attempt to compensate for transmission delay between the time server and the requesting process. The major problem with including time in the authentication protocol is that of synchronization. This is fundamental to the acceptable operation of the protocol so that a private key will not be compromised. A compromised key may lead to the impersonation of either a client or the authentication service itself. This in turn can lead to a security breach of the whole network. Playback attacks can be lessoned by a sense of ‘currency’. If authentication is to be current then an absolute sense of time must be introduced into the network. This requires complete synchronization of all network clocks. Synchronization may be possible within 1 second over local area networks but for long-haul networking this may not be achievable. The prevention of playback attacks can also be obtained without the use of universal clocks and
J.M. Power and S.R. Wilbur / Authentmtion
46
their associated penalties. This can be achieved by the use of event markers [9] which are both local and private in the sense that no external synchronization or coordination between communicants is required. It is important when choosing event markers that the following two conditions exist: e The sequence of event markers must be chosen so that at any point in the sequence the next marker is not predictable. l Any cycles must be long so that specific event markers are used again only after long intervals of time.
5. Description of System 5.1. Protection
Offered
The authentication procedure relies on several assumptions which influence the protection it provides. The first of these is that the authentication service which holds all secret keys is secure. Secondly, it is assumed that the encryption algorithm itself is secure. We are concerned with protecting our machines and services from any unauthorised access. This does not include the need for all data to be transmitted in ciphertext nor does it mean that all services will have restricted access. On the contrary, many of our services such as lineprinters and common filestores will remain unauthenticated. It is important to note that this system provides authentication of principals. Clients, acting on behalf of a principal (user), communicate with servers. Thus, in nested transactions of this kind, several principals may be involved, e.g. the originating client’s principal, those of the intermediate servers, and possibly others such as the principals who installed or wrote the servers. The present approach ignores this multitude and handles one principal at a time, whichever the transaction originator considers most appropriate. The presence of multiple administrations further complicates matters. In this paper we consider single administration requests and then show how this can be extended to multiple administration requests.
in o Heterogeneous
5.2. Authenticated
Environment
Stream Protocols
Because of the clock synchronisation problems described above, an alternative protocol using event markers has been explored. However, as described below, it needs more messages to flow between the client and server to achieve the same effects as the ECMA strong protocol. In the protocol, A requests a secure connection by sending its claimed identity and unique (and unpredictable) event marker, EMU, to B. B can then either refuse the connection or enter the protocol. If B continues it requests a conversation key from the authentication service by sending it A’s claimed identity, it’s own identity, A’s event marker and a unique and unpredictable event marker from itself. If both A and B are registered with the authentication service then the authentication service generates a unique conversation key Kc and sends a message to B consisting of two parts: one destined for B and another destined to be forwarded to A from B. This message could be sent to A instead or to A as well as to B. These alternatives are equivalent in terms of the security they provide. The advantage of having the authentication service send both parts to B is that it requires fewer network messages; B can decrypt the first part of this message from the authentication service to learn the conversation key, the intended communicant A, and its original event marker because they are encrypted with B’s private key, Kb. This assures that the authentication service understood B’s request to communicate with A and that that part of B’s request information was not modified by an intruder. If B is careful to change EMb for every connection then it can be sure that the message sent back from the authentication service was not previously recorded and played back. Since the conversation key appears only twice (encrypted under the private keys of A and B), only parties aware of those private keys may learn the conversation key. Continuing the protocol, B forwards to A the portion of the message returned from the authentication service that is encrypted with A’s private key. A decrypts the message to learn the conversation key, Kc, its intended communicant B and its original event marker EMU. This gives A the same assurance B has that the message was from the same source.
J.M. Power and S.R. Wilbur /Authentication
The sequence of events just described is listed below. A-B: B-Au:
A, EMa A, EMa,
B, EMb
Au -+ B: [Kc, A, EMb] B+A:
[Kc,
Kb, [Kc,
B, EMa]
B, EMa]Ka.
Ka (4
A may now encrypt its request to B using Kc and the reply from B can be similarly encrypted. 5.3. Authenticated
Transactions
At UCL we support distributed transactions by means of remote procedure calls. These are based upon a datagram service that operates at the Transport Service level. As indicated in Section 4, the authentication protocol sits above the transaction protocol. Remote Procedure calls have session-like bindings performed for client to server transactions. It is not possible to determine the number of calls that will be made to a particular service at bind-time. Thus, authenticating transactions is similar to authenticating connection-based services. Besides protecting against the obvious threat of faking, the model can be augmented to provide stronger protection against replay attacks in a way that is particularly appropriate for transactions. This is achieved by the receiving side of a call returning a new conversation key (that is randomly generated) along with the data. The calling side decrypts this message with the original conversation key and uses the new key for the next transaction. The receiving side has retained the new key as the legitimate conversation key so that it will only recognise subsequent calls encrypted with this key. 5.4. Authenticating
Unmanaged Services
If a communicating node on the network is not ‘managed’, such as a workstation that has no secure network interface, it may be restricted to a weaker form of authentication. This may also apply to managed services that have no kernel where encryption can be securely carried out. In these cases the authentication protocol described for managed services will not be applicable. It is imperative, when a request is made of a
in o Heterogeneous
Environment
41
service, that it can determine whether the requesting client is authenticated to a sufficient degree of confidence. When strong authentication is not available to a client, it might be acceptable for certain services to condone authenticated requests of a weaker nature. If a machine is ‘managed’ and does not support a secure network interface, it is possible to employ a slightly modified version of the managed machine protocol. This would entail having a client on such a machine, A, contact a service B, which in turn refers to its authentication service to find out the strength of A’s authentication. If it is strong authentication then the protocol proceeds as outlined above. Otherwise, A will be asked by either B or the authentication service to resend a password that corresponds to the one used initially for registration with that service. If it matches the registered password then the service can inform B that it believes that A is authentic. Similarly, the same procedure can be repeated with the service and B so that A can be informed that the service believes that B is who it says it is. It is up to the two parties involved, A and B, to decide if this is enough assurance to continue the communication. For a machine where there is no trusted protection, another approach is necessary. If a client wishes to authenticate itself to a service then the strongest form of authentication it can attain is by sending a password (possibly in cleartext) together with the address of a managed network node which has a copy of its password to the authentication service. The service then forwards this encrypted information to the selected node for confirmation. If there is a match at the node then the authentication service sends a message to the requested service, B, that it believes A is who it claims to be. This scheme could just as easily be carried out between A and a selected node before contact with the authentication service. In this case the authentication service would be informed by the managed node of the partial authentication. This could be done in tandem with the unmanaged node contacting the authentication service to inform it of its intent to request a remote service. It is important to note that in both of these ‘unmanaged’ cases the authentication is not completely secure, particularly in the latter case. This degraded form of authentication is suggested to provide some form of multiple level service.
J.M. Power and S.R. Wtlbur / Authentication
48
5.5. Multiple Authentication
Services
It is possible that more than one authentication service may be desired. This could be for reasons of reliability, performance or possibly for organisational demarcation and management. Bauer et al. have proposed a protocol [lo] that accommodates this situation which is a natural extension of the modified ECMA model we have outlined. Given two communicants, A and B, the protocol proceeds as before but with the added addresses of A’s and B’s authentication services. A sends B its own identity, the address of its authentication service, ASa, and a unique event marker, EMa. B then sends its own authentication service, ASb, the identity of A, A’s event marker, the address of A’s authentication service, its own identity (B), and a unique event marker, EMb. B’s authentication service responds by sending to A’s authentication service the identity of A, the identity of B, A’s event marker and an event marker of its own, EMasb. The inclusion of this last event marker is to protect ASb from playback attacks. A’s authentication service then generates a conversation key, encrypts the message eventually destined for A under A’s private key and returns ASb’s event marker. B’s event marker is encrypted with the conversation key under a secret key, Kx, that is known to the two authentication services. If the use of exchange keys is felt to be too much of a risk for the network then further authentication can be implemented between the two services. The extended protocol outlined is listed below: A + B: A, EMa,
ASa
B-A:
B, EMb EMasb
[Kc, B, EMa]
AS6 -+ B: [Kc, A, EMb] [Kc, B, EMu]Ka.
The transaction exchanged between
Environment
has its own key so that penetration of one scheme does not compromise the other. The simple scheme is felt to be inappropriate in environments where network messages can be observed by intruders. Even if stronger management approaches are used, such as short duration keys, the management of these becomes difficult where multiple authenticators are involved. The strong model is much more robust, but does rely on network-wide clock synchronisation. Dangers are seen in using the present scheme in batch systems with long queuing delays. To overcome this, schemes which use event markers are being investigated. They in turn introduce additional transactions, leading to a power performance protocol. Multiple administration authentication adds further to the message content.
Acknowledgement
This work was supported in part by grant number B/83700480 from the Science and Engineering Research Council in the United Kingdom. References
111Rank
Xerox
Standard
PI
Contribution,
ECMA
Needham,
R.M.
and Schroeder,
for Authentication
Authentication
September
- Draft Proposal,
M.D.,
Using Encryption of Computers, CACM
in Large Networks
21, 12. pp. 993-999,
December
Serulce
1984.
1978.
rn Office [31 Israel, J.E. and Linden, T.A., Authentication System Internetworks, ACM Trans. on Office Information Systems 1, 3, pp. 1933210,
July 1983.
[41 Denning, D.E. and Sacco, G.M., Timestamps in Key Distrrbution Protocols, CACM 24, 8, pp. 533-536, August 1981.
B +ASb: A, EMa, ASa, ASb -ASa: A. B, EMa, ASa + ASb:
in a Heterogeneous
Ka, [Kc, EMasb]
[51 Berson, T.A. and Bauer, R.K., Local Cryptosystem Architecture, Proceedings of Spring Compcon 1982, IEEE Com-
Kx
Kb, [Kc, B, EMa]Ka (5)
request and reply can not be A and B under Kc.
puter Society
November
The ECMA proposal considered uses two authentication schemes, one strong and one simple. Each
February
1982.
1982.
[71 FIPS Publication Bureau
46, Data Encryption
of Standards,
PI Newman, Logica
6. Conclusions
Press, pp. 138-143,
[61 Watson, R.W. and Nessett, D.M. and Sorkin, A.R., Connectton Management and Key Distribution Protocols, UCRL-88345 Preprint, Lawrence Livermore Laboratory,
B.B.,
U.K.,
Washington,
Encryption
Standard,
D.C., January
ooer the Universe
National 1977.
Network.
April 1982.
[91 Lamport, L., Time, Clocks and the Ordermg of Events m a Distrrbuted System, CACM 21, 7, pp. 558-565, July 1978. UOI Bauer, R.K. and Berson, T.A. and Feiertag, R.J., A Key Dwtribution Protocol Using Event Markers, ACM Transactions 1983.
on Computer
Systems
1. 3, pp. 249-255,
August
in a Heterogeneous
June M. Power and Steve R. Wilbur Department of Computer Science, Gower Street, London WCIE 6BT
University
1. Introduction
College London,
This paper considers how a mechanism might be set up to provide authentication of users and servers. The scheme proposed aims to deal with simple processors which are unmanaged, as well as managed timesharing systems. It would provide authentication tokens which can be included in the applications protocols. Much of the difficulty of the scheme is concerned with building a distributed secure database for private keys. Keywords: Authentication, Protection, Security, Distributed systems
June Power’s first degree was an A.B. in Computer Science from the University of California at Berkeley. She has been a resident in the U.K. since 1979 and received an M.Sc. in Computer Science from University College London in 1983. Since then she has been a research student at the same college, specialising in the area of Protection in Distributed Systems.
In a distributed system clients on one machine may access services on another. Even if management arranges that the coded user identification (uid) is identical on both (all) machines, passing such uids in unencrypted messages may lead to penetration of important resources by unauthorised third parties. There are several forms of attack which can be made on network based systems: Eavesdropping: listening to conversations which are private and making use of the contents in other transactions. Faking: generating messages or replaying earlier legitimate messages to gain resources for which the faker is not authorised. Trojan Horse: pretending to offer a service, perhaps even offering it, but gathering information which allows impersonation of clients on other servers. Our local distributed system is vulnerable to these attacks, especially faking and the use of Trojan Horses. This paper explores possible solutions.
2. The Environment Steve Wilbur graduated in Electrical Engineering in 1966, and obtained an MSc. in Computer Science in 1968. His early career interests were in computer aided design and operating systems. More recently his research has been concerned with local area networks and distributed systems, leading the University College team in Project Universe. He is now principal investigator of Project Admiral sponsored by the UK Department of Industry as part of its Alvey Programme. Important aspects of these projects are the integration of local and wide-area high speed services and the management of applications and networks spanning several administrations. Particular areas of study include: remote procedure call, naming, security, and distributed system structuring.
North-Holland Computers & Security 6 (1987) 41-48 0167-4048/87/$3.50
The University College London, Department of Computer Science (UCL-CS) environment consists of a number of local area networks (LANS) which are interconnected and have gateways to other external networks. Various service time sharing (Unix) machines are attached to the LANS, as are a variety of communications servers, file servers and microprocessors. At present, various machines authenticate users when they begin a session. However, such authentication only serves one machine, although having been authenticated a uid is often passed between machines by specific applications. Thus, authentication currently may allow terminal access at a given time to machine A, and file transfer to machines B, C, D provided the uid is also valid there, but no terminal access
0 1987, Elsetier Science Publishers B.V. (North-Holland)
-
-. .i, . .~ -
Fig.1.
-
link
-
._,
RING
_
-
MICRO--LAB RING
UNIVERSE
3 68000 Codata workstations *
SUN bridge
:
I t
To
A
MRC ULCC
x.25
act
_
dataqrams X.25
machines
._ ,_,
I
.”
under
I I I
._
KILOSTREAM
To
Area
-
-
run BSD 2.8 (like Version have ethernet connection can be used.
_ _ ,“_
All may 2.9
Local
.._._
/-
possible ethernet connections
Terminal gateways. Handle Network Service system access to UCL and o,,t to PSS, JANET and the ARPA internet.
7 UNIX) (if BSD
Networks
Science
Departmental
Computer
J.M. Power and S.R. Wilbur / Authentication
to B, C, D without further authentication. The file transfer protocol itself is insecure, since users on any of the machines with direct network access could inject messages containing any uid, including the privileged user id. Servers are found by name-to-address mapping in a name table. It is difficult but not impossible to change this table and interpose a fake server (Trojan Horse) between the client and true server. Equally, if a legitimate server moves, and another eventually takes over its old address, the client and possibly the server would like to be aware of this, rather than trying to perform an inappropriate action. Thus, besides having authentication of users, there is a need for authentication of servers too. The environment being considered is shown in Figs. 1 and 2. Mm are managed machines, in that users are authenticated when they begin a terminal session, and that access to the LAN is via a managed kernel. In principle, the kernel could prohibit access to the LAN, and certainly would provide a limited set of modes of access. The unmanaged machines, Mu, do not have any such secure network interface; thus there is no way of, say, preventing such users from listening to all transactions on the LAN or changing the node’s network address if the hardware permits such functions. The server machines, MS, may either fall into the same category as Mm, or may have a kernel which is available in source form to some users, i.e. the kernel may be protected/privileged at run-time to limit faults and share functions, but
in a Heterogeneous
appl icat 10” kernel
R,-
managed
machine
Mu - unmanaged machine MS - server machine Mg -gateway machlne Fig.2.
43
may be changed by the user at development time to include new functions. Finally, the gateway machines, Mg, are generally similar to MS, except they have to impose access control between the LAN and WAN.
3. The Models is currently working on a draft proposal for authentication [l] based largely on the earlier papers by Needham and Schroeder [2] and Israel and Linden [3]. In the ECMA document two forms of authentication are proposed, strong and simple. “Strong” is intended to resist attack, but may impose computational delays at execution time, whereas “ simple” is fast but much weaker. The strong approach uses the DES algorithm for encryption. Needham and Schroeder propose an alternative based on PKC, which is interesting but even more computationally demanding than DES based approaches. PKC will not be considered further in this document, the intention being to see whether the ECMA models are adequate for a heterogeneous environment such as UCL-CS. ECMA
3.1. Simple Model The protocol for the ECMA model is shown below.
simple authentication
A +B: A, Ksa B --, Au: A, Ksa Au-+B: b B-A:
a-
Environment
Ksa
(1)
where A is the name of the initiating client, B is the name of the recipient or server, Au is the authentication service, Ksa is A’s simple key and b is a Boolean variable which indicates whether or not Ksa is A’s simple key. The client sends its name A, key, Ksa, and a transaction request to the server. In turn, the server contacts an authenticator and asks for these to be validated, whereupon a suitable response is returned. Presumably to prevent fake results being returned to A, its key is returned with the results. All messages are in cleartext, i.e. no encryption is used at any point in these transactions. Ksa is private to A, and is also known to the authenticator. Management of keys is not dealt with in the
44
J.M. Power and S.R. Wdbur / Auihentication
ECMA proposal, and as a minimum there needs to be a per session or per transaction exchange of the form:
A +Au:
A, Pwd
Au-A:
Ksa
(2) where Pwd is some token for authenticating A. Clearly any eavesdropper observing the plain text Ksa or Pwd at (1) or (2) can pose as A. This simple approach therefore seems to be most appropriate for distributed systems where access to protocol messages is impossible because of physical security, or where low grade resources are being protected. Another approach would be for the authenticator to be able to generate a sequence of keys, each session or transaction having a different one. The management issues appear to be difficult, since there may be many processes owned by A and also multiple authenticators. Keeping all keys in step even in a perfectly reliable environment would be difficult, but in the face of intermittent loss of messages and re-transmission, it is felt that this scheme needs considerable further study. 3.2. Strong Model The protocol for the ECMA strong model is shown below. It relies on encryption and assumes that all network nodes have a reasonably well synchronised clock. A +Au:
A, B, I
B-A:
Environmen
together with sufficient information to pass the key to B and verify that the message containing the key has not been replayed. The client contacts the authenticator (Au) giving its own name, that of B and a random number called the nonce which will not be used again for a long time, and cannot be predicted. Au then invents a new key, Kc, for the conversation, which it encrypts together with the name of A and an expiry time (several hours away, typically) with B’s private key. It then takes this coded data, the name of B, the nonce, and Kc and encrypts them with A’s private key. Thus, only A can decrypt it and check the nonce. The Kb encrypted data is passed to B, together with the current time of day, XORed with the processor ID of B. The purpose of this is to prevent replay of messages, in that only a small amount of time should have elapsed during the transaction between A and B. The scheme is largely that of Needham and Schroeder, but with expiry time and transmission time included [4,.5]. The inclusion of time poses two problems, namely keeping the clocks of each machine sufficiently synchronised for the scheme to work and making the scheme work in batch or buffered systems as opposed to directly coupled systems.
4. Implementation
Issues
4. I. Protocol Hierarchy
Au + A: [[Kc, Texp, A + B: [Kc, Texp,
m a Heterogeneous
A]Kb,
I, B, Kc] Ka
A] Kb, [Ti XOR PIDb] Kc
[TjXORPIDb]Kc
(3)
where [ ]Ka means that the quantity between the square brackets is encrypted under A’s private key and [ ]Kb and [ ]Kc are equivalent for B’s private key and the conversation key, respectively. A and B are the names of the initiator and recipient, I is a random number called the nonce, Texp is the expiration time for a set of credentials, Ti is a time stamp obtained from the system clock at time i, Tj is a time stamp obtained from the system clock at a later time than Ti and PIDb is the processor ID of B. The authenticator knows the private keys of both the client and server, and when the client asks to be authenticated, a conversation key Kc is returned which can be used to encrypt the data,
Two broad families of protocols have to be authenticated. One is stream protocols, the other is transaction protocols. It is not considered necessary at present to cover threats at the protocol level, and indeed the scheme developed will suffer many of the deficiences outlined by Watson [6]. Thus, the authentication protocol sits above both the stream and transaction protocols. In the case of stream protocols, the stream would be opened in the normal way. Once established, or in parallel, the client will obtain the relevant credentials from the authenticator, unwrap them and pass the conversation key to the server. The server in turn will give a handshake to this message. Both message and handshake will be carried over the newly established stream. Thereafter, all data messages are encrypted as discussed below. Protocol messages are not encrypted, so an
J.M. Power and S.R. Wilbur / Authentication
interloper could inject fake resets or resequence packets. This kind of threat is considered to be acceptable. For transaction protocols, there is an initial session-like binding performed by client to server in the scheme currently in use. At that stage the client asks to be bound to one of several servers for a particular service. This binding mechanism must be extended to include the exchange of credentials which then hold until the binding is terminated. It is possible for a client to be bound to several servers simultaneously. In such cases the conversation keys used should all be unique, so that discovery of one key does not compromise all servers. 4.2. Encryption
Algorithm
Performance
If encryption is to be used, it must not significantly degrade performance. The ECMA proposal suggests use of the Data Encryption Standard (DES) [7] for encryption, but in the U.K. the use of DES encryption chips is tightly controlled. Other encryption algorithms could be used, but they would necessarily prevent interworking with proper implementations. Software based encryption has been considered, and according to Newman [8] software performance of around 2Kbps can be achieved on a 16-bit machine for data blocks of 16 X 8 bytes. Such performance is significantly inferior to that of our stream or transaction protocols and is unacceptable where very short messages are involved. Following Newman’s work our early implementations will use additive stream cipher mode (ASC). In this, a pseudo-random number generator is used to produce 64-bit values which are encrypted by DES in advance, and then xoa-ed with the text as it is being sent or received. Present 16-bit machines can perform such stream ciphering at rates of the order of 100 Kbps. 4.3. Key Storage and Distribution Distributing keys is extremely difficult, and encipherment is useless unless the key management is secure. In terminal systems it may be tempting to have users be responsible for keys. This does not solve the problem, however, as it depends upon the individual’s security system. The problem is being passed to users and they often cannot be trusted!
in a Heterogeneous
Environment
45
We are concerned about the problem of users and therefore find it useful to investigate the storage of keys in the system and their distribution. Not all the systems that we are dealing with have human users interacting with them. Servers may need to be re-booted in the middle of the night and so there is need for an automatic secure key distribution mechanism for such machines. In general we believe this to be an intractable problem. However, one solution which is being pursued is to introduce a security kernel in a front-end processor which is inaccessible to the normal user. Another aspect of the problem is whether the key storage should be centralised or distributed. A centralised approach is attractive from the point of view of management, but it would be unacceptable for such a vital part of the system to become disabled. Thus a distributed and replicated approach is favoured. In many respects the problems of key storage are largely traditional database problems with the added complications of security. 4.4. Time The ECMA standard includes the notion of “Universal Time” (UT), which is held accurately (unspecified but approximately 1 second) in each machine. A time server must be provided to ensure this. The time protocol should attempt to compensate for transmission delay between the time server and the requesting process. The major problem with including time in the authentication protocol is that of synchronization. This is fundamental to the acceptable operation of the protocol so that a private key will not be compromised. A compromised key may lead to the impersonation of either a client or the authentication service itself. This in turn can lead to a security breach of the whole network. Playback attacks can be lessoned by a sense of ‘currency’. If authentication is to be current then an absolute sense of time must be introduced into the network. This requires complete synchronization of all network clocks. Synchronization may be possible within 1 second over local area networks but for long-haul networking this may not be achievable. The prevention of playback attacks can also be obtained without the use of universal clocks and
J.M. Power and S.R. Wilbur / Authentmtion
46
their associated penalties. This can be achieved by the use of event markers [9] which are both local and private in the sense that no external synchronization or coordination between communicants is required. It is important when choosing event markers that the following two conditions exist: e The sequence of event markers must be chosen so that at any point in the sequence the next marker is not predictable. l Any cycles must be long so that specific event markers are used again only after long intervals of time.
5. Description of System 5.1. Protection
Offered
The authentication procedure relies on several assumptions which influence the protection it provides. The first of these is that the authentication service which holds all secret keys is secure. Secondly, it is assumed that the encryption algorithm itself is secure. We are concerned with protecting our machines and services from any unauthorised access. This does not include the need for all data to be transmitted in ciphertext nor does it mean that all services will have restricted access. On the contrary, many of our services such as lineprinters and common filestores will remain unauthenticated. It is important to note that this system provides authentication of principals. Clients, acting on behalf of a principal (user), communicate with servers. Thus, in nested transactions of this kind, several principals may be involved, e.g. the originating client’s principal, those of the intermediate servers, and possibly others such as the principals who installed or wrote the servers. The present approach ignores this multitude and handles one principal at a time, whichever the transaction originator considers most appropriate. The presence of multiple administrations further complicates matters. In this paper we consider single administration requests and then show how this can be extended to multiple administration requests.
in o Heterogeneous
5.2. Authenticated
Environment
Stream Protocols
Because of the clock synchronisation problems described above, an alternative protocol using event markers has been explored. However, as described below, it needs more messages to flow between the client and server to achieve the same effects as the ECMA strong protocol. In the protocol, A requests a secure connection by sending its claimed identity and unique (and unpredictable) event marker, EMU, to B. B can then either refuse the connection or enter the protocol. If B continues it requests a conversation key from the authentication service by sending it A’s claimed identity, it’s own identity, A’s event marker and a unique and unpredictable event marker from itself. If both A and B are registered with the authentication service then the authentication service generates a unique conversation key Kc and sends a message to B consisting of two parts: one destined for B and another destined to be forwarded to A from B. This message could be sent to A instead or to A as well as to B. These alternatives are equivalent in terms of the security they provide. The advantage of having the authentication service send both parts to B is that it requires fewer network messages; B can decrypt the first part of this message from the authentication service to learn the conversation key, the intended communicant A, and its original event marker because they are encrypted with B’s private key, Kb. This assures that the authentication service understood B’s request to communicate with A and that that part of B’s request information was not modified by an intruder. If B is careful to change EMb for every connection then it can be sure that the message sent back from the authentication service was not previously recorded and played back. Since the conversation key appears only twice (encrypted under the private keys of A and B), only parties aware of those private keys may learn the conversation key. Continuing the protocol, B forwards to A the portion of the message returned from the authentication service that is encrypted with A’s private key. A decrypts the message to learn the conversation key, Kc, its intended communicant B and its original event marker EMU. This gives A the same assurance B has that the message was from the same source.
J.M. Power and S.R. Wilbur /Authentication
The sequence of events just described is listed below. A-B: B-Au:
A, EMa A, EMa,
B, EMb
Au -+ B: [Kc, A, EMb] B+A:
[Kc,
Kb, [Kc,
B, EMa]
B, EMa]Ka.
Ka (4
A may now encrypt its request to B using Kc and the reply from B can be similarly encrypted. 5.3. Authenticated
Transactions
At UCL we support distributed transactions by means of remote procedure calls. These are based upon a datagram service that operates at the Transport Service level. As indicated in Section 4, the authentication protocol sits above the transaction protocol. Remote Procedure calls have session-like bindings performed for client to server transactions. It is not possible to determine the number of calls that will be made to a particular service at bind-time. Thus, authenticating transactions is similar to authenticating connection-based services. Besides protecting against the obvious threat of faking, the model can be augmented to provide stronger protection against replay attacks in a way that is particularly appropriate for transactions. This is achieved by the receiving side of a call returning a new conversation key (that is randomly generated) along with the data. The calling side decrypts this message with the original conversation key and uses the new key for the next transaction. The receiving side has retained the new key as the legitimate conversation key so that it will only recognise subsequent calls encrypted with this key. 5.4. Authenticating
Unmanaged Services
If a communicating node on the network is not ‘managed’, such as a workstation that has no secure network interface, it may be restricted to a weaker form of authentication. This may also apply to managed services that have no kernel where encryption can be securely carried out. In these cases the authentication protocol described for managed services will not be applicable. It is imperative, when a request is made of a
in o Heterogeneous
Environment
41
service, that it can determine whether the requesting client is authenticated to a sufficient degree of confidence. When strong authentication is not available to a client, it might be acceptable for certain services to condone authenticated requests of a weaker nature. If a machine is ‘managed’ and does not support a secure network interface, it is possible to employ a slightly modified version of the managed machine protocol. This would entail having a client on such a machine, A, contact a service B, which in turn refers to its authentication service to find out the strength of A’s authentication. If it is strong authentication then the protocol proceeds as outlined above. Otherwise, A will be asked by either B or the authentication service to resend a password that corresponds to the one used initially for registration with that service. If it matches the registered password then the service can inform B that it believes that A is authentic. Similarly, the same procedure can be repeated with the service and B so that A can be informed that the service believes that B is who it says it is. It is up to the two parties involved, A and B, to decide if this is enough assurance to continue the communication. For a machine where there is no trusted protection, another approach is necessary. If a client wishes to authenticate itself to a service then the strongest form of authentication it can attain is by sending a password (possibly in cleartext) together with the address of a managed network node which has a copy of its password to the authentication service. The service then forwards this encrypted information to the selected node for confirmation. If there is a match at the node then the authentication service sends a message to the requested service, B, that it believes A is who it claims to be. This scheme could just as easily be carried out between A and a selected node before contact with the authentication service. In this case the authentication service would be informed by the managed node of the partial authentication. This could be done in tandem with the unmanaged node contacting the authentication service to inform it of its intent to request a remote service. It is important to note that in both of these ‘unmanaged’ cases the authentication is not completely secure, particularly in the latter case. This degraded form of authentication is suggested to provide some form of multiple level service.
J.M. Power and S.R. Wtlbur / Authentication
48
5.5. Multiple Authentication
Services
It is possible that more than one authentication service may be desired. This could be for reasons of reliability, performance or possibly for organisational demarcation and management. Bauer et al. have proposed a protocol [lo] that accommodates this situation which is a natural extension of the modified ECMA model we have outlined. Given two communicants, A and B, the protocol proceeds as before but with the added addresses of A’s and B’s authentication services. A sends B its own identity, the address of its authentication service, ASa, and a unique event marker, EMa. B then sends its own authentication service, ASb, the identity of A, A’s event marker, the address of A’s authentication service, its own identity (B), and a unique event marker, EMb. B’s authentication service responds by sending to A’s authentication service the identity of A, the identity of B, A’s event marker and an event marker of its own, EMasb. The inclusion of this last event marker is to protect ASb from playback attacks. A’s authentication service then generates a conversation key, encrypts the message eventually destined for A under A’s private key and returns ASb’s event marker. B’s event marker is encrypted with the conversation key under a secret key, Kx, that is known to the two authentication services. If the use of exchange keys is felt to be too much of a risk for the network then further authentication can be implemented between the two services. The extended protocol outlined is listed below: A + B: A, EMa,
ASa
B-A:
B, EMb EMasb
[Kc, B, EMa]
AS6 -+ B: [Kc, A, EMb] [Kc, B, EMu]Ka.
The transaction exchanged between
Environment
has its own key so that penetration of one scheme does not compromise the other. The simple scheme is felt to be inappropriate in environments where network messages can be observed by intruders. Even if stronger management approaches are used, such as short duration keys, the management of these becomes difficult where multiple authenticators are involved. The strong model is much more robust, but does rely on network-wide clock synchronisation. Dangers are seen in using the present scheme in batch systems with long queuing delays. To overcome this, schemes which use event markers are being investigated. They in turn introduce additional transactions, leading to a power performance protocol. Multiple administration authentication adds further to the message content.
Acknowledgement
This work was supported in part by grant number B/83700480 from the Science and Engineering Research Council in the United Kingdom. References
111Rank
Xerox
Standard
PI
Contribution,
ECMA
Needham,
R.M.
and Schroeder,
for Authentication
Authentication
September
- Draft Proposal,
M.D.,
Using Encryption of Computers, CACM
in Large Networks
21, 12. pp. 993-999,
December
Serulce
1984.
1978.
rn Office [31 Israel, J.E. and Linden, T.A., Authentication System Internetworks, ACM Trans. on Office Information Systems 1, 3, pp. 1933210,
July 1983.
[41 Denning, D.E. and Sacco, G.M., Timestamps in Key Distrrbution Protocols, CACM 24, 8, pp. 533-536, August 1981.
B +ASb: A, EMa, ASa, ASb -ASa: A. B, EMa, ASa + ASb:
in a Heterogeneous
Ka, [Kc, EMasb]
[51 Berson, T.A. and Bauer, R.K., Local Cryptosystem Architecture, Proceedings of Spring Compcon 1982, IEEE Com-
Kx
Kb, [Kc, B, EMa]Ka (5)
request and reply can not be A and B under Kc.
puter Society
November
The ECMA proposal considered uses two authentication schemes, one strong and one simple. Each
February
1982.
1982.
[71 FIPS Publication Bureau
46, Data Encryption
of Standards,
PI Newman, Logica
6. Conclusions
Press, pp. 138-143,
[61 Watson, R.W. and Nessett, D.M. and Sorkin, A.R., Connectton Management and Key Distribution Protocols, UCRL-88345 Preprint, Lawrence Livermore Laboratory,
B.B.,
U.K.,
Washington,
Encryption
Standard,
D.C., January
ooer the Universe
National 1977.
Network.
April 1982.
[91 Lamport, L., Time, Clocks and the Ordermg of Events m a Distrrbuted System, CACM 21, 7, pp. 558-565, July 1978. UOI Bauer, R.K. and Berson, T.A. and Feiertag, R.J., A Key Dwtribution Protocol Using Event Markers, ACM Transactions 1983.
on Computer
Systems
1. 3, pp. 249-255,
August