Klaus Gaarder
Security and privacy in intelligent networks is treated as a case of security and privacy in distributed systems. We consider the concepts of security policies and security domains. The enforcing of security policies in intelligent networks is given special attention, and interdomain problems are seen as one of the major challenges. Authentication, authorisation, data security and security management are discussed in broad terms and with some examples from services like UPT and VPN. We finally consider formal methods of description and specification combined with object orientation as possible tools. The paper aims to give an initial analysis of some security issues in intelligent networks.
Intelligent networks will offer advanced information processing and networking of computers directly to the general public. The terminal equipment in our homes will probably consist of "workstation-like" multi-purpose machines. As increasingly advanced services pervade our daily work we will need to have assurance of their security properties. That is, we must feel assured that information we want to keep private stays private, and that information we trust and depend on to be correct, stays correct, etc. Put in terms of what is to be discussed in this paper the intelligent network must be able to enforce a very wide variety of security policies, ranging from rather simple to quite restrictive.
The intelligent network and its services must provide a sufficient variety of security functionality to satisfy every user. This is so because the intelligent network is not just a part of the future telecommunications network but it is the future telecommunications network.
As indicated above, the security problem is essentially the problem of enforcing a security policy. Many texts dealing with security aspects of computer systems tend to give the impression that security is mainly about encryption and secrecy (confidentiality), security levels, authentication protocols, etc., or that absolute standards and references exist, which is not true. Security is a truly relativistic subject, and the frame of reference is always given by, and only by a security policy. Note that "national security" provides no absolute reference, it is just another (time dependent) policy, although for many cases it is used as some sort of "default" policy or baseline.
Throughout the paper we assume some familiarity with the intelligent network concepts and refrain from any elaboration on these unless necessary for the clarity of exposition.
One of the basic ideas of the intelligent network is the separation of service logic from switching logic. An effective abstraction of this is to view the intelligent network as consisting of two logically separate "domains", the service domain (S) and the switching domain (X) (see Figure 1). Services reside in S while connections and other communications specific facilities are placed in X. A well-defined interface between S and X takes care of the interactions between the two domains.
A close analogy is an application on a workstation with network communications functions. The application is running on your computer, supported by the operating system and communications software and hardware. It may, or it may not communicate with other applications without the user being explicitly aware of this. Most important is that you do not worry about how this happens, as long as it works satisfactorily.
This view reduces the switches and network to a basic communications "engine" acting as a provider of connectivity. The services need only know that this connectivity is there when they need it and they can ask for communication whenever they want to. Still the communications can be seen as an "add-on" to most services (though some would look silly without, e.g. Plain Old Telephone Service, which basically is only communication).
The services can in general be viewed as distributed applications on this network (5). (A service which is centralised can be viewed as trivially distributed on one node.) In general, there will be different situations where distribution is natural or preferable for various reasons. However, we may see that many services of the intelligent network will be of limited interest if they are not distributed. The Universal Personal Telecommunications (UPT), Universal Access Number (UAN) and Virtual Private Network (VPN) services are prime examples of this. This leads us to conclude that in order to have an unrestrained view the intelligent network is best considered as an open distributed system on the public switched network.
An immediate conclusion is that security and privacy in intelligent networks essentially reduce to security and privacy in distributed systems. We cannot see technically new security problems in the intelligent network that are not present in a general open distributed system. The general security issues are the same even if the applications are to some extent different. The differences between a completely general open distributed system and the intelligent network lies in the policy structures we may see. This will be further elaborated on below. We are then in a position to discuss security and privacy in intelligent networks on a firm basis, since security in distributed systems is a well established area of research. Henceforth we will consider results on security in open distributed systems as equally valid for intelligent networks security. Whenever "security", "security policy", etc. is used, it is to be understood in this context unless otherwise indicated.
As indicated in the introduction the term "secure" is a relativistic term. Questions like "Is this secure?" or "Has there been a security breach?" are meaningless or at best very hard to answer unless we are given a frame of reference, a security policy. The following definition of security policy is from (1):
Definition 1 (Security Policy): A set of rules which define and constrain the types of security-relevant activities of entities.
The definition captures the fact that a security policy is a collection of statements on
Note that in order to avoid a circular definition the term "security" in this definition has to be interpreted as a qualitative concept established by those who are defining the security policy. What this means is always hard to decide, and is one of the crucial questions we have to answer when designing a security policy. In regular business contexts the usual practice will often be to put some economic measure on what you are doing and decide what it will cost in terms of labour and money to restore what has been compromised or lost. In some cases this is easy and in other cases it is almost impossible.
The only way we can "define" security quantitatively is by reference to some given security policy:
Definition 2: An object is secure if and only if its state is in compliance with the security policy enforced.
Security policy is violated if an object fails to meet one or more of the requirements set by the security policy.
This definition is not very precise (the state of an object is unclear), but it carries the necessary message that security is always relative to some security policy and nothing else. There does not exist a thing such as absolute security, simply because there is no reference.
A nice analogy is the law of ordinary society. What is allowed in one state may be prohibited in another and thus "breaking the law" is a relative concept. This also means that if no security policy exists, no violations of security can exist (no law means no lawbreakers)!
The concept of a security domain has turned out to be very useful in structuring complex security scenarios. A security administration as defined by (1) is
Definition 3: A human authority which establishes a security policy and identifies the entities to which the policy applies.
The security domain is then associated with security administrations in the following definition of a security domain (1):
Definition 4: A security domain is a set of entities (objects) that is subject to a single security policy and a single security administration.
Security domains are the domains of jurisdiction of a security administration. The way they are defined, security domains may form hierarchies. They will either be disjoint or one completely included in the other (since it seems reasonable that no object may be partially under purview of one policy and partially another, since nothing guarantees that these two policies are consistent with one another). The world, seen from a security point of view, may now be partitioned into a patchwork of security domains, each defined by its security policy. To decide which security requirements apply to an object, decide which domain it belongs to and check the security policy for that domain.
Problems occur when objects move from one security domain to another. If the two domains are part of the same hierarchy there is usually some pre-defined procedure to take care of this. If the two domains are disjoint then we may have what we call an interdomain problem. The two policies may be incompatible in some respects or even incomparable in others. Traditionally such problems are solved by negotiation in each case or each class of cases. However, in our days of increasingly fast electronic business this is not always possible or desirable, so the problem will have to be solved by other means.
The reason why interdomain problems are so hard to deal with is due to several factors among which the lack of possible standardisation is one. We believe it is impossible, maybe even meaningless to standardise security policies. The only possible subject of standardisation is on the implementation side. Some of the mechanisms for implementing and enforcing security policies may be given standard forms. The ECMA Privilege Attribute Certificate (PAC) and Control Attribute Package (CAP) are attempts at this for open distributed systems, hence also applicable to intelligent networks. We refer the reader to (2) and (1) for details.
We believe interdomain problems will be one of the most challenging security issues in intelligent networks in particular and distributed systems in general. This is due to the fact that interdomain activities is not an exception but a rule in doing business.
In this section we consider security in the explicit context of the intelligent network. First we discuss general security policy issues. Then we move on to discuss authentication, authorisation, data security and security management in broad terms, with some examples from e.g. UPT and VPN.
For the remaining part of this paper it will be assumed that for any situation, we are under the jurisdiction of some security policy, and every object will be assumed to belong to some security domain. This is just to ensure that talking about security will always be meaningful.
There will be security domains for the different actors on the scene, like service provider, subscriber, user and network operators, etc. Certain relations between these domains (or policies) will be given by some unavoidable physical facts of the network. The network operators will typically require their policies to be enforced with regard to the security of the network operations, we could call this the "network policy". Hence, as all services use this network, they will have to comply with this network policy in addition to whatever policy they have of their own. Network policy may be seen as a bottom (or top) level of a policy hierarchy in the sense that all services must comply with it, their own policies considered a "refinement" of it.
The exact relations between the different policies will be important for the way we handle security in intelligent networks. Among other things this will decide the extent of interdomain problems we will encounter. Consider the following policy structure, where Pi Í Pj means the first policy is included in the second, i.e. all rules of Pi are in Pj .
P1.1
P1 Í {
P1.2
P0 Í { P2
P3.1
P3 Í {
P3.2
Here we may have well defined relations between P0 and all other policies, since they are all including P0 . The more refined (with respect to P0 ) policies P1.2 and P3.2 may have to go to P0 to find a common ground to resolve interdomain activities. A possible solution in this case could be to define a separate interdomain policy, dictating rules for interaction with other domains. (A simple such policy is "If Px is a sub- policy of this policy it's OK, else NO INTERACTION".) In the absence of such simple general rules, an interdomain policy could be quite involved and maintenance will be a major problem.
We believe that the policy structures of the intelligent network will be significantly more complex than the example above. It should be a prime task to investigate how we can best accommodate these various structures.
The authentication problem is the problem of verifying the identity of entities. Or as (1) defines it
Definition 5 (Authentication): The process by which the identity of an entity is established.
Authentication can be done in a multitude of ways, some of which are simple (e.g. simple passwords, PIN codes) and some which are rather complicated (e.g. zero-knowledge protocols or interactive proof systems). In recent research on security, authentication has been receiving growing attention. This is due to the increasing importance of open and distributed systems. In such systems you cannot know at all times who will try to access the system. The other extreme is a system which is only accessible from a single physical location with strongly restricted access. In the intelligent network we must ensure that we can authenticate several kinds of entities, ranging from human users via physical terminal equipment to processes. The requirements for authentication in each case will be stated in an authentication policy to be enforced. The main problems for services providers will be to accommodate all the different varieties of authentication procedures which may be required at all times and all locations. Some standards have been proposed, like the X.509 Authentication Framework protocols. However, formal analysis of these protocols have revealed weakness (e.g. (9, 6)).
Nevertheless, the X.500 recommendations probably give the best starting point for a standard distributed directory service containing public key information and certificates for authentication.
The UPT service will present a typical authentication problem. In a fully developed UPT service it is vital to know who exactly is using the service. A primary reason is billing. It should be exceedingly difficult for a user Alice to masquerade as another user Bob, using his UPT service and making him pay the bill.
The authentication issues in UPT have been recognised by ETSI. It is reasonable to assume that the experiences with the authentication issues in the GSM system will have an important effect on the work with authentication in UPT.
As a UPT user moves around she will pass through differing network segments and thus possibly differing security policies will be in effect in these segments. She may also choose to act either as a professional or as a private person, thus filling different roles with different security policies, possibly requiring different authentication schemes.
One particular problem which may be associated with UAN in particular is the authentication of the service. That is, if Alice calls a UAN she might be interested in being assured that this is in fact the real UAN she wanted, not some fake. Depending on the underlying business of the UAN subscriber this can become a real issue.
There is no reason to regard a virtual network as much different from "real" networks with their requirements for access control. Security may be split between the security in the actual physical network and the VPN service. The enforcement of a VPN security policy may present a significant challenge. VPN is typically a service which in our opinion will be impossible to bring to market without advanced security features present from day 1.
As authentication is a two-party process, there is always possibly a need for authentication for every combination of pairs. If we assume that in the intelligent network we have n generic entities we can at worst risk n2 possible authentication situations requiring differing treatments. However, we believe the following ones to be among the most probable and common (User is a service user agent or a human user in the sense of end user):
User - Service (a user authenticating to a service)
Service - User (a service authenticating to a user)
User - Network (a user authenticating to a network, real or virtual)
Network - User (a network authenticating towards a user)
Subscriber - Provider
Provider - Subscriber
Note the asymmetries arising from possible differences in policy, i.e. the fact that "User - Service" may be different from "Service - User" authentication. Differing policies and requirements will dictate how each of these authentications are to be performed. Another issue which will have to be resolved is the definition of these entities, i.e. what is a "user", "service provider", "service subscriber", etc.
Authorisation is often confused with authentication, because in many situations which we normally encounter there is apparently no difference. Let us quote the following definition from ECMA Standard 138 (1):
Definition 6 (Authorisation):
The process by which an access control decision is made and enforced.
If we follow this definition then authorisation is quite different from authentication, and also from ordinary use of the word. Authorisation is the very process of granting or denying access to resources. That is, an entity is not "authorised" until it is actually granted access. Authorisation is of course tightly coupled to authentication. Some security policies grant access based solely on authentication, while others require further requirements to be fulfilled (like being in possession of certain credentials).
Authorisation policy and authentication policy together form the core of what is called an access control policy. The access control policy decides who can access resources and how (e.g. read, write, execute, etc.). In the intelligent network we will need access control policies for all resources which should have some limitations on their accessibility. Exactly how these are implemented may vary, but we suggest using the privilege attribute and control attributes concepts from the ECMA STD 138 (1). These are general constructs designed for use in open distributed systems, and hence should be suitable also for intelligent networks.
It is hard to point to any particular service on this issue. Any service which may be used to access resources in ways that can be considered harmful will need access control of some sort, which will be decided by the security administration of the domain to which the resources belong. Subscriber and service profiles will be typical entities in need of access control, as will the basic network entities.
Authorisation is often based on ownership to information. Thus, to decide who owns any particular piece of information can become an important issue. Ownership is not always obvious. If we create documents in our business these will typically be regarded as owned by whichever company we work for, or even a customer of this company. Internally in the company ownership may be more refined, relating to smaller units all the way down to persons. Internally the person producing the document may be considered the owner.
The important issue in the intelligent network is to be able to accommodate any such variety of authorisation policy, not to decide which should exist and which should not!
Data security in general involves two aspects: confidentiality and integrity.
To keep certain things from being known to unauthorised persons is a fact of daily life with smart cards, credit cards, etc., passwords and PIN codes of all sorts. (2) defines confidentiality as
Definition 7 (Confidentiality):
A security property of an object that prevents its existence being known and/or its contents being known. This property is relative to some subject population and to some degree of security.
Confidentiality is the classical security problem and thousands of work- years have been spent to find methods of protecting information from unauthorised disclosure. This is the encryption or cryptography business. Equally hard efforts have been put in to break through other people's protection, this is cryptanalysis.
In the intelligent network, confidentiality will be a question of communications security. We regard the confidentiality problems of the customers internally as outside our domain of discourse. Intelligent network services involving transfer and manipulation of information considered security sensitive by some customer will have to provide some sort of protection compliant with the security policies in effect. Usually this will imply the use of encryption under keys known only to authorised entities. Here we run into the more delicate sides of the security business. Due to the importance of cryptographic techniques in international intelligence and military business, heavy restrictions exist in many states. In some states the transfer of encrypted information in the public network is prohibited. These issues are not easily resolved and may put severe limitations on some uses of encryption in intelligent network services.
A definition of integrity to be found in (2) is
Definition 8 (Integrity):
A security property of an object that prevents or is used to prevent its condition of existence being changed and/or its contents being changed. This property is relative to some subject population and to some degree of security.
Integrity of information or other items is less obvious to us. Often we have unconscious mechanisms for assessing the integrity of things, like traces of tampering, obvious flaws which should not be there, etc. However, if Alice sends Bob an electronic message, or calls Bob on the phone, how can he be sure that her message has not been modified on its way or that it is actually Alice talking? These are integrity questions. The last issue could be solved by authenticating Alice to Bob. The first could be solved be means of e.g. a digital signature, which is a cryptographic means of ensuring the integrity of information.
We may find that the demands for maintaining high integrity of information in the intelligent network are larger than those for confidentiality. It is often much more important that the information you receive is known to be uncorrupted than that it should be kept secret. Of course, encryption for secrecy implies uncorrupted information if the key has not been compromised. However, bulk encryption is time consuming and expensive, while integrity can be achieved by simpler means. Thus bulk encryption will often be "over-kill".
Security management concerns the actual operational aspects of a security administration. It is one of the most critical functions in any security system needing to be absolutely trusted by all entities under purview of the particular policy (at least). We must take care not to confuse the ones responsible for security management with the policy makers. The relation is much like the one between legislators and the police. Security management in the intelligent network will be an awesome task.
A primary reason for problems with implementing security in computer systems is that security questions often are considered much too late in the design and engineering process. Introducing security at a late stage is invariably a difficult, time consuming and expensive task. In the intelligent network we will have services which are depending on necessary security services in order to be interesting to the market. No business customer in her right mind would subscribe to a VPN service without the right security being available. This means that service providers must be able to supply security from the start. This means further that security must be an integrated part of the specification of a service. No service can be seen separated from its security aspects.
Based on the the ideas of security facility and security service in (2) we find a similar solution to be the most promising for the intelligent network. This will also tie the intelligent network to work on the OSI based systems like ODP systems.
Definition 9 (Security Service):
A set of operations designed to support some aspect of security in a distributed system. (1)
The idea is that to implement security for some service we have to include the specified functionality in terms of interaction with the relevant security services assumed to exist in the basic configuration of the intelligent network. The main issue to be resolved is then who supplies the security services? If these services are to be used throughout the intelligent network they must be trusted. That is, any client must believe that these services act according to some agreed public specification, and not maliciously. Considering the number of possible customers (on the order of 108) this may seem an insurmountable problem. However, these security services are to be generic, policy independent in the sense that a very wide variety of security policy types may be implemented using these services.
Example. Assuming a service S is to be specified. This service may then be specified to interact with e.g. an authentication service X, for user authentication, an authorisation service Y for authorisation:
S -> X.authenticate(u); (1)
which would require the user u to authenticate herself (or itself if u is a process). Similarly if authorisation with credentials c is required to access a resource r:
S -> Y.authorise(u, c, r); (2)
The ability to unambiguously decide if policy is violated or not is very desirable. This is only possible in a formal policy. Secondly a formal policy gives the possibility of consistency checks, and formal analysis. In the latter case a policy is more like a theory of formal logic. Well known examples of such analysis includes so-called "information flow" analysis done in e.g. the Bell-LaPadula policy (3)1).
The most far reaching reason may be the possibilities of automatic policy enforcement. That is, on-line continuous evaluation of policy rules on security relevant events (which are of course defined in the policy) in a system. In a sense this is of course what happens in any access control system, but only for part of the policy (the access control part).
Algebraic specification (see e.g. (8)) is documented to be well suited for specifying "non-functional" properties of objects like security (12). We shall consider the algebraic specification language(s) called Larch described in (10, 11), as an example. Larch specifications have theories of many-sorted first-order logic with equality as their models. As outlined above, security is basically all about compliance with some security policy. Most security policies can be modelled as first-order theories. If we include in a specification also a specification of a security policy to be enforced for that service then we stand a fair chance of having a service which will fulfill the security requirements expressed in the policy. If this is a formal specification it is possible to formally verify that an implementation is correct with respect to the specification and hence will be in accordance with the security policy which is part of the specification.
We have only hinted at the possibilities of and reasons for formal security policy models and specifications. We refer the interested reader to a mass of published work, e.g. (3, 4, 7) and in general the proceedings of the IEEE Security and Privacy workshop for recent years.
We have discussed in broad terms security issues associated with intelligent networks, with emphasis on the relativistic nature of security with respect to a security policy. The principal point was to consider the intelligent network as a distributed system and use concepts from distributed systems security. The work on security in open distributed systems carries nicely over to intelligent networks. Use of the ECMA defined security service concept is seen as a possible way to implement security in intelligent networks. Formal specification methods should be used to enhance the quality of systems and make possible verification of security properties of services. Formal object oriented techniques are promising and algebraic specification techniques exist which should be tested. Security in intelligent network has to be taken seriously from the start. Satisfactory interdomain security solutions are critical to the successful implementation of reasonable security in intelligent networks (as it is in all open distributed systems).
We have only scratched the surface of a huge problem, and several important issues have been left out, but work will continue to solve the security problems of intelligent networks one by one.
1 ECMA Standard 138 Security in Open Systems, Data Elements and Service Definitions. Geneva, 1989. (ECMA/TC32/TG9/89/.)
2 Security in Open Systems A Security Framework. Geneva, 1988. (ECMA TR/46, ECMA/TC32/TG88/.)
3 Bell, D E, LaPadula, L J. Secure computer system: Unified exposition and multics interpretation. Mitre Corporation, 1976. (Technical Report ESD-TR-75-306.) (This is the so-called Bell-LaPadula Model.)
4 Brewer, D F C, Nash, M J. The Chinese wall security policy. In: Proceedings IEEE Symposium on Security and Privacy, 1989, 206-214.
5 Bugge, B et al. Methods and tools for service creation in an intelligent network. Kjeller, Norwegian Telecom Research, 1991. (TF N34/91.)
6 Burrows, M, Abadi, M, Needham, R. A logic of authentication. ACM Transactions on Computer Systems, 8, 18-36, 1990.
7 Clark, D D, Wilson, D R. A comparison of commercial and military security policies. In: Proceedings IEEE Symposium on Security and Privacy, 1987, 184-194.
8 Ehrig, H, Mahr, B. Fundamentals of Algebraic Specification 1. Berlin, Springer-Verlag, 1985. (EATCS Monographs on Theoretical Computer Science; volume 6.)
9 Gaarder, K, Snekkenes, E. Applying a formal analysis technique to the CCITT X.509 strong two-way authentication protocol. Journal of Cryptology, 3, 81-98, 1991.
10 Guttag, J V, Horning, J J, Modet, A. Report on the larch shred language: Version 2.3. Digital Equipment Corporation, Systems Research Center, 1990. (Technical Report TR 58.)
11 Guttag, J V, Horning, J J, Wing, J M. Larch in five easy pieces. Digital Equipment Corporation, Systems Research Center, 1985. (Technical Report TR 5.) Superseded by DEC SRC TR 58.
12 Wing, J M. Using larch to specify avalon/c++ objects. IEEE Transactions on Software Engineering, 16, 1076-1088, 1990. (Special issue on formal methods.) ÿ