Previous section.

Technical Study: Security in Federated Naming

Technical Study: Security in Federated Naming
Copyright © 1997 The Open Group

Name Service Threats and Countermeasures

This chapter outlines the generic threats to IT systems and describes the nature of a name service architecture to set the context for the subsequent discussion of name service specific security concerns, specific threats and appropriate countermeasures.

Generic Threats

The Distributed Security Framework (XDSF) categorises the generic threats to IT systems as follows:

These generic threats are realised by specific actions or sets of actions. For example, eavesdropping on a communications channel may reveal user passwords. Those passwords may then be used to enable the user who eavesdropped to masquerade as other users. The XDSF describes the many ways in which the generic threats above may be realised and also describes generic measures that may be deployed to counter these threats. This chapter identifies the threats that are specific to a name service.

As well as threats arising from unauthorised operations threats also arise from the irresponsible or malicious exercise of authorised operations. It may not be possible to prevent threats arising from authorised operations. however, by recording and analysing system operations it may be possible to deter such behaviour, or react and recover promptly to its occurrence.

Name Service Architecture

A name service is typically implemented as a client-server architecture, as described in Federated Naming Specification (XFN) , and may be considered to have the following aspects from a security viewpoint:

Name Service Security Policy Concerns


Name services are a critical component of distributed systems providing a service via which users and applications may locate objects with which they require to interact. The availability and responsiveness of name services therefore have a direct impact upon the overall usability and responsiveness of a whole system. An attack on the availability of a name service may be used as the basis of a denial of service attack on a system or other individual services.


The maintenance of the integrity of the binding of a name to an object is a fundamental requirement of a naming service. The modification or destruction of a binding between a name and an object may lead to attacks on other system services through denial of service or through masquerade. Denial of service can arise from an inability to locate a service, masquerade attempts can occur through deliberate modification of a binding or interference with the name resolution process resulting in a caller interacting with a subverted object.

Associated with the integrity of the binding of a name to an object, a security policy may require uniqueness of the binding of a name to an object. A name should only refer to a unique object. If a name does not refer to a unique object then any reliance upon that binding, for example in support of authentication, is compromised. The existence of multiple bindings to a single object may or may not be a security concern.

This requirement for uniqueness may be extended in time to also cover the reuse or re-assignment of names. This is of particular security significance in the context of the historic analysis of security audit trails for which the binding information needs to be preserved. Note that a binding may actually reference multiple instances of a single object, or a distributed object, for the purposes of resilience.

Also note that in some namespaces the re-assignment of names is a fundamental part of the operation of applications. For example, in the filesystem namespace a wordprocessing application frequently updates a document by creating a new object, a file, renaming the original file as a backup and re-assigning the document name to the new object. In this example the uniqueness in the binding is between a name and a user concept of a document. The mapping between the document object and a filesystem object varies according to a policy enforced by the appropriate application.

If the name server also supports the assignment of attributes to objects then the integrity of that assignment may also be significant if the attributes are used for security related purposes.


In the context of a naming service, confidentiality is generally of lesser importance than integrity and availability. It is of significance if the revealing of the existence or location of objects or of attributes assigned to objects is subject to control under the applicable security policy.

An example may be an enterprise policy prohibiting disclosure of information about the enterprise's user and service namespaces to principals that are not part of the enterprise.


A security policy is likely to require principals that modify binding and attribute information to be held accountable for their actions. This is often likely to particularly apply to the principals with administrative authority over a name service. Accountability is generally enforced through the use of a security audit service to record security significant events and their subsequent analysis.

Data Store Threats

Destruction or corruption of a name server's database may be used to attack the availability of a name service. That is, unauthorised modification can lead to denial of service.

Unauthorised modification of a name server's database may be used to attack the integrity of the name service.

Read access to a name server database may be used to attack the confidentiality of name service information, that is unauthorised disclosure.

Threats and appropriate countermeasures include:

Communication Service Threats

Interference with communication services offer the opportunity to affect the availability, integrity and confidentiality of name services.

Threats and appropriate countermeasures include:

Analysis of Name Service Requests

An analysis of name service requests may reveal information about a client's activities, for example which trading partners it is currently dealing with. This may be countered to some extent by "traffic padding", that is, generating false requests to mask the real reqests.

Programming Interface Threats

Threats and appropriate countermeasures include:

Generic Countermeasures

The following countermeasures do not relate to individual threats but form part of an overall protective environment:

Access Control within Name Services

Name services are frequently integrated with other services, such as a filesystem, directory service, etc. As such there is no single generic access control policy applicable to all instances of a name service. However, it is possible to discuss some commonly applicable policy types, and these are addressed in this section.

Context Functions

These may be subject to an access control policy if they require name resolution to be performed. See Name Resolution functions below.

Name Resolution Functions

Name resolution functions are often offered to anonymous principals. For a significant set of name services, such as DNS, the identity of an individual user is irrelevant for access control policy enforcement and accountability is not a concern. What is more likely to be relevant for access control purposes is the enterprise or organisational unit affiliation of a user. In this case the user principal does not require to be authenticated to the name service but a client may have to present a security attribute representing the enterprise or organisational unit. The name server needs to be able to verify the authenticity of that security attribute.

In some services, for example a file system, name resolution functions such as listing the names within a context are subject to a similar access control policy to the access control policy that applies to access to the objects themselves.

Binding and Attribute Management Functions

In general a name service security policy is concerned with the accountability of individual user principals for the use of functions that create, modify, an destroy bindings and object attributes. The support of such accountability requires the authentication of individual user principals and the propagation of that information between the name service components participating in the operation.

The access control policy enforced on binding and attribute management may be based on a concept of the possession of authorities for the execution of a subset of a name services functions or on the basis of a relationship to the object, for example ownership or specifically assigned access rights.

Possession of authority is frequently linked with administrative responsibility for aspects of the name service and may be represented by a capability or privilege mechanism.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index