- Email: [email protected]
An inter-bridge-security protocol
496
Computer Networks and ISDN Systems 25 (1992) 496-500 North-Holland
Security
An inter-bridge-security protocol Peter Lipp and Reinhard
Posch
lnstitut fiir Angewandte Informationsverarbeitung Klosterwiesgasse 32, A-8010 Graz, Austria
und Kommunikationstechnologie,
Technische Universitiit Graz,
Abstract
Lipp, P, and R. Posch, An inter-bridge-security protocol, Computer Networks and ISDN Systems 25 (1992) 496-500. Local area networks offer a wide range of possibilities to intruders, especially if connected by a backbone network. By adding intelligence and encryption to the connectingpoints, bridges, a control of access to the local subnet and a possibility to secure communication by encrypting at network-speed is provided. Keywords: local area networks; network security; cryptography;bridges.
I. Introduction Networks at universities often share a structure similar to the one shown in Fig. 1. Independent departments own independent local networks which can be connected by a backbonenetwork or by other means. There may be distinct networks for special departments, like studentlabs or administration offices. All these departments have very different needs for security: - A very high level of security is usually needed in administrative departments where personal and highly confidential data is processed. They might also need a highly secure and dependable communication possibility to the departments. - The security level needed in departments varies from one to another. While some may need the same high-level security as above, others might think that the level of security the oper-
Correspondence to: Dr. P. Lipp, Institut fiir Angewandte In-
formationsverarbeitung und Kommunikationsteehnologie, Teehnische Universitiit Graz, Klosterwiesgasse 32, A-8010 Graz, Austria. Tel. (+43) 316 826588 13, Fax (+43) 316 826588 20, E-mail: [email protected].
ating system offers is sufficient for their purposes. - Student labs differ very much in their security needs too. Labs equipped with PCs are inherently very insecure and form a security threat to the environment. Other labs, equipped with workstations, are better off. In general, student labs would need a high level of security, to protect the network-cluster from attacks of students, who often are eager to exploit the weaknesses of the systems they use, but because of e.g. financial reasons, such a level cannot be provided very often. In many cases there is no central management of the network-cluster or the central management is practically unable to control the operation of the network efficiently. Concerning security, it is well known that local area networks offer a wide range of possibilities to intruders [...]. To be able to evaluate overall security in a cluster of networks, we have to look at the individual networks first. Roughly two classes of networks (in the sense of security controllability) can be identified: Class A networks, where a high level of security can be provided locally by organizational and physical means and where personnel can be
0169-7552/92/$05.00 © 1992 - Elsevier Science Publishers B.V. All rights reserved
P. Lipp / Inter-bridge security protocol
497
external connection (e.g.Internet)
Fig. 1. A typical structure of a university network.
higly t r u s t e d ; C l a s s B n e t w o r k s , w h e r e t r u s t is less appropriate and organizational and physical cont r o l is n o t s u f f i c i e n t l y e f f e c t i v e o r c a n n o t b e e n forced for whatever reasons. Examples of Class A
networks are administrative offices or departm e n t s , o f C l a s s B n e t w o r k s s t u d e n t labs o r d e p a r t m e n t s w i t h a less r e s t r i c t i v e c o n t r o l - s c h e m e . A s s e c u r i t y in a g l o b a l s y s t e m always d e p e n d s o n
Peter Lipp was born in 1958 in Graz. He received his Ph.D. in technical mathematics/information processing at Graz University of Technology in 1989 and is currently Assistant Professor at the Institute of Applied Information Processing and Communications Technology at the Graz University of Technology. His main interests are computer security, local area networks and operating systems. Currently he is involved in projects related to network security.
Reinhard Posch was born in 1951 in Graz. He studied information processing at the Graz University of Technology and received his Ph.D. in 1977. Since 1984 he has been a full Professor. He is Head of the Institute of Applied Information Processing and Communications Technology at the Graz University of Technology. His main interests are telecommunication and data transmission. At present he is involved in a number of projects in the area of network security, local area networks and VLSI design.
P. Lipp / Inter-bridge security protocol
498
the weakest element it contains, the whole cluster cannot be viewed as being secure, if there is a single Class B network connected to it. In the following, security is looked at from the point of view of a user of a Class-A-subnet in such a cluster of networks and for the time being we are deliberately neglecting the inherent problem of enforcing security by whatever means. We assume that all users of the local subnet are trustworthy and some physical protection hinders others to access the cable or equipment. We do not assume trust in other subnets or the backbone network. If, for some reason, trust in the local subnet would not be appropriate, the whole subnet must be modified and described as a cluster of very small networks, each consisting of a single host, which then could be protected by the same means.
2.
Improving
security
One possible starting-point to improve security can be the connecting point to the "outside world", that is the point where the local subnet is connected to the backbone network. Limiting access to the local subnet can only be done there and has positive influences on the level of security achieved. We not only want to passively protect the subnet; we want to provide a secure way to communicate with other machines. As a change of protocols or applications is impractical, because software for different hardware- and operating-system-platforms would have to be changed, a solution that is (more or less) transparent to existing software is called for. In our special environment, where we assumed a certain level of security in the local subnet, the possibility we have chosen is to provide for secure communication between two subnets by implementing secure communication between the corresponding connection points. Connecting two networks can be done by bridges, routers or gateways. In our environment bridges are the most frequently used devices for connecting a local ethernet-segrnent to the FDDI-backbone. Bridges frequently are adaptive, i.e. they learn addresses of connected stations by listening to the traffic and inspecting the sourceaddress-fields of the packets passing by. Normally this does indeed add a little security to the opera-
tion of the network: no user of another subnet can accidentally receive a packet not sent to a station in his subnet. In reality, this does not mean a lot; nearly any ethernet-controller is able to send out packets using chosen source and destination addresses; so this minimum feature can easily be nullified. Its main purpose is to reduce the traffic fed into a subnet-segment from the backbone network. Routers are much better in the sense of adding security. They can usually be programmed to restrict traffic to certain protocols and stations. But most of them are rather expensive, so they are normally used only to connect a cluster of local networks to an external network, like the internet, and to enable local routing between different subnets in the cluster. They do not provide for secure communications between two subnets or hosts. This is why we decided to use a bridge as the basis for our development. By removing the weaknesses and adding other features we wanted to develop a good solution to our problems by using low-cost hard- and software components. The bridge prototype consists of a PC containing two to four network adapters and is able to connect more than one subnet to the backbone network. Two functions are provided by the bridge: (a) The protection of the local environment by restricting packets passing the bridge according to a simple filtering-scheme. (b) The protection of data transmitted from the local subnet to another subnet in the cluster (which then has to be protected by another bridge of this kind). Filtering is done by checking packets arriving at any of the adapters using a filtering table. This table is initially loaded at startup-time from the hard disk and contains filter specifications restricting traffic by the following attributes: (a) One address-pair, specifying two communication partners. Any address can be a real address (ethernet), broadcast-address, multicast-address (wildcards), or internet-address. (b) The time-period when this communication is allowed (from-to, anytime). (c) A list of protocols allowed (e.g. T C P / I P , D E C N E T . . . . ).
499
P. Lipp ~Inter-bridge security protocd
The filtering table can be modified at runtime by a remote management station. The bridge sends the current state to the requesting management-station. After modification of the table it is sent back to the bridge which, after checking the plausibility, immediately starts to use it.
3. S e c u r i n g d a t a c o m m u n i c a t i o n
In addition to restricting traffic, there is also the need to enable secure communication between two subnets, which are connected to the backbone by this type of bridge. Two such bridges can arrange for encryption of data exchanged on a certain connection of two hosts wishing to communicate. The only critical problem to be addressed is encryption-speed. In general, the following possibilities exist: - asymmetric encryption (public key) - symmetric encryption (e.g., DES) - stream-ciphers (Vernam) Public key-encryption would be the first choice; it is recognized as being highly secure; keymanagement is not a big problem; it would be relatively easy to add another bridge into the system. The main drawback is encryption speed: high-speed solutions are currently unavailable. Current state-of-the-art encryption-rates are totally inadequate for network-transmission. Symmetric algorithms, such as DES or FEAL, are much faster (up to 100 k b / s in Software), but still not fast enough for our purposes; a significant delay would still be encountered. Streamciphers like Vernam-cipher do not suffer from this deficiency; an xor-operation between key and data could easily be performed at network-speed. The problem is, that a key of the same length as the data to be encrypted is needed; the key has to be transported via some secret channel. This seems to rule out this solution immediately; but there is a possibility to use a combination of techniques, that allows us to make use of the advantages of these methods and still fulfill the requirements, if only for a restricted amount of data that can be encrypted per time-unit. What we do is to use public key techniques to calculate the Vernam-key-stream, which is then used for encrypting data in transmission. In the startup-phase two bridges exchange starting-values secretly.
BA BI~
SVA,,SV~2 .... SV~. SVRI .SV82 .... SVB~
,BB 'BA
Each of them creates random numbers SV/ and transmits them encrypted using RSA and the public key of the partner-bridge. Each startingvalue is then used to calculate a sequence e
e
f ,( svk ) ,f 2( svk ) ..... L (
)e
where fi is a function which modifies the starting value such that even plaintext attacks will not reveal the value of SV and can be calculated as easy as for example L ( S V ) = ( S V + i)
To make plaintext attacks totally ineffective, we could also restrict the amount of key generated by one starting value to an amount that crypographic analysis would show to be secure and then switch to the next starting value. The only limit of this method is the amount of key that can be generated. As the main task of the bridge is receiving, inspecting, discarding and forwarding packets, the calculation of the key can either be done in the idle-time of the bridge, or using a specialized co-processor. Using the idletime of the bridge we measured that we can generate approximately half-a-megabit of the key per hour (using a 664 bit key and an Intel 80486 based PC using state-of-the-art RSA-Software). This is clearly not enough for real-life-applications. Especially when more than two bridges want to communicate that way, the availability of the Vernam-key cannot be guaranteed. We expect hardware-RSA-modules to be able to encrypt up to 40 KBytes per second in the near future. This should then be adequate for most real applications. If a user wants to set up such a secure channel between his and another subnet, he sends the appropriate request to the bridge protecting his subnet, allocating a certain amount of key for the communication. This bridge then evaluates if enough key has been generated for the request and tries to get into contact with the bridge protecting the partner's subnet. If successful, the request is then acknowledged. All transmission between the user's machine and his partner is then done over the secure channel between the two bridges.
500
P. Lipp / Inter-bridge security protocol
4. Drawbacks
Two drawbacks have to be mentioned: (1) The RSA-key the bridges use to generate the Vernam-key has to be shared by two bridges. This makes the solution comparable to others using symmetric encryption algorithms. If RSAencryption will be available at sufficient speed, the Vernam cipher can be replaced by direct encryption using the public key/private key pair. (2) The process of requesting a secure channel can currently only be set up by hand or integrated into special applications. As long as the solution can only secure a limited amount of data, this situation will persist. If the encryption-process is fast enough to enable encryption of all data transferred between two subnets, the process of setting up a secure connection will no longer be necessary.
5. Conclusion
The solution presented here shows that it is possible to add security to communication in network speed. Currently only a very limited amount of data can be securely transferred this way. This will be improved in the near future by the development of high-speed encryption devices, which also might make network-speed encryption eventually possible.
References [1] T.A. Berson, ed., Local Area Network Security, Workshop LANSEC'89, European Inst. for System Security
(E.I.S.S.), Lecture Notes in Comput. Sci. 396 (Springer, Berlin, 1989). [2] R. Brand, Coping with the thread of computer security incidents: a primer from prevention to recovery, June 1990, available online from cert.sei.cmu.edu:/pub /info/primer. [3] B. Cheswick, The design of a secure internet gateway, Proc. Summer Usenix Conference, Anaheim, CA, June 1990. [4] J. Cooper, Computer and Communications Security: Strategies for the 1990s (McGraw-Hill, New York, NY, 1990). [5] D. Curry et al., Site Security Handbook, RFC 1244, July 1991. [6] P. Denning, Computers under Attack. Intruders, Worms and Viruses (ACM, New York, NY, 1990). [7] IEEE Network, The Magazine of Computer Communications, Vol. 2, No. 1, January 1988, Special Issue on Bridges and Routers. [8] P. Lipp and R. Posch, Security issues when implementing a hierarchical cluster of local area networks, EUROSEC'90, Paris, October 1990. [9] P. Lipp and R. Posch, Sicherheitsaspekte beim Zusammenschlu lokaler Netze, LANSEC 1990, Karlsruhe, November 1990. [10] J. Linn, Privacy Enhancement for lnternet Electronic Mail: Part I: Message Encryption and Authentication Procedures, lnternet-Draft ll13E, 10 April 1992. [11] S. Kent, Privacy Enhancement for lnternet Electronic Mail: Part 11: Certificate-Based Key Management, Internet-Draft ll14F, 23 March 1992. [12] D. Balenson, Privacy Enhancement for lnternet Electronic Mail: Part II1: Algorithms, Modes and Identifiers, lnternet-Draft I 115C, April 1992. [13] B. Kalisi, Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services, lnternet-Draft FORMS-E, 15 April 1992. [14] C. Pfleeger, Security in Computing (Prentice Hall, Englewood Cliffs, NJ, 1989). [15] CCIqq" Recommendation X.509 (1988), The Directory - Authentication Framework.
Computer Networks and ISDN Systems 25 (1992) 496-500 North-Holland
Security
An inter-bridge-security protocol Peter Lipp and Reinhard
Posch
lnstitut fiir Angewandte Informationsverarbeitung Klosterwiesgasse 32, A-8010 Graz, Austria
und Kommunikationstechnologie,
Technische Universitiit Graz,
Abstract
Lipp, P, and R. Posch, An inter-bridge-security protocol, Computer Networks and ISDN Systems 25 (1992) 496-500. Local area networks offer a wide range of possibilities to intruders, especially if connected by a backbone network. By adding intelligence and encryption to the connectingpoints, bridges, a control of access to the local subnet and a possibility to secure communication by encrypting at network-speed is provided. Keywords: local area networks; network security; cryptography;bridges.
I. Introduction Networks at universities often share a structure similar to the one shown in Fig. 1. Independent departments own independent local networks which can be connected by a backbonenetwork or by other means. There may be distinct networks for special departments, like studentlabs or administration offices. All these departments have very different needs for security: - A very high level of security is usually needed in administrative departments where personal and highly confidential data is processed. They might also need a highly secure and dependable communication possibility to the departments. - The security level needed in departments varies from one to another. While some may need the same high-level security as above, others might think that the level of security the oper-
Correspondence to: Dr. P. Lipp, Institut fiir Angewandte In-
formationsverarbeitung und Kommunikationsteehnologie, Teehnische Universitiit Graz, Klosterwiesgasse 32, A-8010 Graz, Austria. Tel. (+43) 316 826588 13, Fax (+43) 316 826588 20, E-mail: [email protected].
ating system offers is sufficient for their purposes. - Student labs differ very much in their security needs too. Labs equipped with PCs are inherently very insecure and form a security threat to the environment. Other labs, equipped with workstations, are better off. In general, student labs would need a high level of security, to protect the network-cluster from attacks of students, who often are eager to exploit the weaknesses of the systems they use, but because of e.g. financial reasons, such a level cannot be provided very often. In many cases there is no central management of the network-cluster or the central management is practically unable to control the operation of the network efficiently. Concerning security, it is well known that local area networks offer a wide range of possibilities to intruders [...]. To be able to evaluate overall security in a cluster of networks, we have to look at the individual networks first. Roughly two classes of networks (in the sense of security controllability) can be identified: Class A networks, where a high level of security can be provided locally by organizational and physical means and where personnel can be
0169-7552/92/$05.00 © 1992 - Elsevier Science Publishers B.V. All rights reserved
P. Lipp / Inter-bridge security protocol
497
external connection (e.g.Internet)
Fig. 1. A typical structure of a university network.
higly t r u s t e d ; C l a s s B n e t w o r k s , w h e r e t r u s t is less appropriate and organizational and physical cont r o l is n o t s u f f i c i e n t l y e f f e c t i v e o r c a n n o t b e e n forced for whatever reasons. Examples of Class A
networks are administrative offices or departm e n t s , o f C l a s s B n e t w o r k s s t u d e n t labs o r d e p a r t m e n t s w i t h a less r e s t r i c t i v e c o n t r o l - s c h e m e . A s s e c u r i t y in a g l o b a l s y s t e m always d e p e n d s o n
Peter Lipp was born in 1958 in Graz. He received his Ph.D. in technical mathematics/information processing at Graz University of Technology in 1989 and is currently Assistant Professor at the Institute of Applied Information Processing and Communications Technology at the Graz University of Technology. His main interests are computer security, local area networks and operating systems. Currently he is involved in projects related to network security.
Reinhard Posch was born in 1951 in Graz. He studied information processing at the Graz University of Technology and received his Ph.D. in 1977. Since 1984 he has been a full Professor. He is Head of the Institute of Applied Information Processing and Communications Technology at the Graz University of Technology. His main interests are telecommunication and data transmission. At present he is involved in a number of projects in the area of network security, local area networks and VLSI design.
P. Lipp / Inter-bridge security protocol
498
the weakest element it contains, the whole cluster cannot be viewed as being secure, if there is a single Class B network connected to it. In the following, security is looked at from the point of view of a user of a Class-A-subnet in such a cluster of networks and for the time being we are deliberately neglecting the inherent problem of enforcing security by whatever means. We assume that all users of the local subnet are trustworthy and some physical protection hinders others to access the cable or equipment. We do not assume trust in other subnets or the backbone network. If, for some reason, trust in the local subnet would not be appropriate, the whole subnet must be modified and described as a cluster of very small networks, each consisting of a single host, which then could be protected by the same means.
2.
Improving
security
One possible starting-point to improve security can be the connecting point to the "outside world", that is the point where the local subnet is connected to the backbone network. Limiting access to the local subnet can only be done there and has positive influences on the level of security achieved. We not only want to passively protect the subnet; we want to provide a secure way to communicate with other machines. As a change of protocols or applications is impractical, because software for different hardware- and operating-system-platforms would have to be changed, a solution that is (more or less) transparent to existing software is called for. In our special environment, where we assumed a certain level of security in the local subnet, the possibility we have chosen is to provide for secure communication between two subnets by implementing secure communication between the corresponding connection points. Connecting two networks can be done by bridges, routers or gateways. In our environment bridges are the most frequently used devices for connecting a local ethernet-segrnent to the FDDI-backbone. Bridges frequently are adaptive, i.e. they learn addresses of connected stations by listening to the traffic and inspecting the sourceaddress-fields of the packets passing by. Normally this does indeed add a little security to the opera-
tion of the network: no user of another subnet can accidentally receive a packet not sent to a station in his subnet. In reality, this does not mean a lot; nearly any ethernet-controller is able to send out packets using chosen source and destination addresses; so this minimum feature can easily be nullified. Its main purpose is to reduce the traffic fed into a subnet-segment from the backbone network. Routers are much better in the sense of adding security. They can usually be programmed to restrict traffic to certain protocols and stations. But most of them are rather expensive, so they are normally used only to connect a cluster of local networks to an external network, like the internet, and to enable local routing between different subnets in the cluster. They do not provide for secure communications between two subnets or hosts. This is why we decided to use a bridge as the basis for our development. By removing the weaknesses and adding other features we wanted to develop a good solution to our problems by using low-cost hard- and software components. The bridge prototype consists of a PC containing two to four network adapters and is able to connect more than one subnet to the backbone network. Two functions are provided by the bridge: (a) The protection of the local environment by restricting packets passing the bridge according to a simple filtering-scheme. (b) The protection of data transmitted from the local subnet to another subnet in the cluster (which then has to be protected by another bridge of this kind). Filtering is done by checking packets arriving at any of the adapters using a filtering table. This table is initially loaded at startup-time from the hard disk and contains filter specifications restricting traffic by the following attributes: (a) One address-pair, specifying two communication partners. Any address can be a real address (ethernet), broadcast-address, multicast-address (wildcards), or internet-address. (b) The time-period when this communication is allowed (from-to, anytime). (c) A list of protocols allowed (e.g. T C P / I P , D E C N E T . . . . ).
499
P. Lipp ~Inter-bridge security protocd
The filtering table can be modified at runtime by a remote management station. The bridge sends the current state to the requesting management-station. After modification of the table it is sent back to the bridge which, after checking the plausibility, immediately starts to use it.
3. S e c u r i n g d a t a c o m m u n i c a t i o n
In addition to restricting traffic, there is also the need to enable secure communication between two subnets, which are connected to the backbone by this type of bridge. Two such bridges can arrange for encryption of data exchanged on a certain connection of two hosts wishing to communicate. The only critical problem to be addressed is encryption-speed. In general, the following possibilities exist: - asymmetric encryption (public key) - symmetric encryption (e.g., DES) - stream-ciphers (Vernam) Public key-encryption would be the first choice; it is recognized as being highly secure; keymanagement is not a big problem; it would be relatively easy to add another bridge into the system. The main drawback is encryption speed: high-speed solutions are currently unavailable. Current state-of-the-art encryption-rates are totally inadequate for network-transmission. Symmetric algorithms, such as DES or FEAL, are much faster (up to 100 k b / s in Software), but still not fast enough for our purposes; a significant delay would still be encountered. Streamciphers like Vernam-cipher do not suffer from this deficiency; an xor-operation between key and data could easily be performed at network-speed. The problem is, that a key of the same length as the data to be encrypted is needed; the key has to be transported via some secret channel. This seems to rule out this solution immediately; but there is a possibility to use a combination of techniques, that allows us to make use of the advantages of these methods and still fulfill the requirements, if only for a restricted amount of data that can be encrypted per time-unit. What we do is to use public key techniques to calculate the Vernam-key-stream, which is then used for encrypting data in transmission. In the startup-phase two bridges exchange starting-values secretly.
BA BI~
SVA,,SV~2 .... SV~. SVRI .SV82 .... SVB~
,BB 'BA
Each of them creates random numbers SV/ and transmits them encrypted using RSA and the public key of the partner-bridge. Each startingvalue is then used to calculate a sequence e
e
f ,( svk ) ,f 2( svk ) ..... L (
)e
where fi is a function which modifies the starting value such that even plaintext attacks will not reveal the value of SV and can be calculated as easy as for example L ( S V ) = ( S V + i)
To make plaintext attacks totally ineffective, we could also restrict the amount of key generated by one starting value to an amount that crypographic analysis would show to be secure and then switch to the next starting value. The only limit of this method is the amount of key that can be generated. As the main task of the bridge is receiving, inspecting, discarding and forwarding packets, the calculation of the key can either be done in the idle-time of the bridge, or using a specialized co-processor. Using the idletime of the bridge we measured that we can generate approximately half-a-megabit of the key per hour (using a 664 bit key and an Intel 80486 based PC using state-of-the-art RSA-Software). This is clearly not enough for real-life-applications. Especially when more than two bridges want to communicate that way, the availability of the Vernam-key cannot be guaranteed. We expect hardware-RSA-modules to be able to encrypt up to 40 KBytes per second in the near future. This should then be adequate for most real applications. If a user wants to set up such a secure channel between his and another subnet, he sends the appropriate request to the bridge protecting his subnet, allocating a certain amount of key for the communication. This bridge then evaluates if enough key has been generated for the request and tries to get into contact with the bridge protecting the partner's subnet. If successful, the request is then acknowledged. All transmission between the user's machine and his partner is then done over the secure channel between the two bridges.
500
P. Lipp / Inter-bridge security protocol
4. Drawbacks
Two drawbacks have to be mentioned: (1) The RSA-key the bridges use to generate the Vernam-key has to be shared by two bridges. This makes the solution comparable to others using symmetric encryption algorithms. If RSAencryption will be available at sufficient speed, the Vernam cipher can be replaced by direct encryption using the public key/private key pair. (2) The process of requesting a secure channel can currently only be set up by hand or integrated into special applications. As long as the solution can only secure a limited amount of data, this situation will persist. If the encryption-process is fast enough to enable encryption of all data transferred between two subnets, the process of setting up a secure connection will no longer be necessary.
5. Conclusion
The solution presented here shows that it is possible to add security to communication in network speed. Currently only a very limited amount of data can be securely transferred this way. This will be improved in the near future by the development of high-speed encryption devices, which also might make network-speed encryption eventually possible.
References [1] T.A. Berson, ed., Local Area Network Security, Workshop LANSEC'89, European Inst. for System Security
(E.I.S.S.), Lecture Notes in Comput. Sci. 396 (Springer, Berlin, 1989). [2] R. Brand, Coping with the thread of computer security incidents: a primer from prevention to recovery, June 1990, available online from cert.sei.cmu.edu:/pub /info/primer. [3] B. Cheswick, The design of a secure internet gateway, Proc. Summer Usenix Conference, Anaheim, CA, June 1990. [4] J. Cooper, Computer and Communications Security: Strategies for the 1990s (McGraw-Hill, New York, NY, 1990). [5] D. Curry et al., Site Security Handbook, RFC 1244, July 1991. [6] P. Denning, Computers under Attack. Intruders, Worms and Viruses (ACM, New York, NY, 1990). [7] IEEE Network, The Magazine of Computer Communications, Vol. 2, No. 1, January 1988, Special Issue on Bridges and Routers. [8] P. Lipp and R. Posch, Security issues when implementing a hierarchical cluster of local area networks, EUROSEC'90, Paris, October 1990. [9] P. Lipp and R. Posch, Sicherheitsaspekte beim Zusammenschlu lokaler Netze, LANSEC 1990, Karlsruhe, November 1990. [10] J. Linn, Privacy Enhancement for lnternet Electronic Mail: Part I: Message Encryption and Authentication Procedures, lnternet-Draft ll13E, 10 April 1992. [11] S. Kent, Privacy Enhancement for lnternet Electronic Mail: Part 11: Certificate-Based Key Management, Internet-Draft ll14F, 23 March 1992. [12] D. Balenson, Privacy Enhancement for lnternet Electronic Mail: Part II1: Algorithms, Modes and Identifiers, lnternet-Draft I 115C, April 1992. [13] B. Kalisi, Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services, lnternet-Draft FORMS-E, 15 April 1992. [14] C. Pfleeger, Security in Computing (Prentice Hall, Englewood Cliffs, NJ, 1989). [15] CCIqq" Recommendation X.509 (1988), The Directory - Authentication Framework.