Security in Federated Naming - Implications of Security on XFN

Technical Study: Security in Federated Naming

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

Implications of Security on XFN

Mapping of XFN to XDSF Concepts

A basic concept of the Distributed Security Framework (XDSF) is to view an IT system as comprised of a set of interacting and in some cases interdependent security domains. A security domain is defined as " A set of elements, a security policy, a security authority and a set of security-relevant operations in which the set of elements are subject to the security policy, administered by the security authority, for the specified activities". At this level each service (or application) can be viewed as an individual security domain enforcing its own security policy over the application entities within the domain. Each service or application services principals, that is users or other services, that are external to the service or application.

Services are provided by the exchange of information across the domain boundary. The service can only identify the principal via information exchanged between the principal and the service. In order to prevent the masquerade of one principal by another the identification information supplied requires authenticating.

The service may exercise access control on the basis of the authenticated identity, or it may associate other security attributes with the identity for the purposes of mediating authorisation to access entities or exercise activities of the service. For example security attributes may include group affiliation, authorities or privileges, role, etc.

Security Domains in XFN Operation illustrates the security domains involved in the implementation of XFN. Each name service that is integrated as part of XFN comprises a security domain in its own right. The entities within the domain are the bindings and object attributes maintained by the name service for the namspace that it services. Each name service enforces a security policy over the operations it provides to access and maintain those bindings and attributes in that namespace.

Figure: Security Domains in XFN Operation

The application client invoking the XFN API executes within a security domain representing an end user principal or a system service principal. Associated with the application client is a security context that includes the authenticated identity of the principal and any security attributes associated with the principal within that domain.

In invoking the services of a name server the XFN implementation must propagate the appropriate parts of the security context, normally at least the principal identity, to the underlying name service. The name service will require to verify the authenticity of the information it is passed.

In the context of the XDSF, the distributed security services provide an authentication service and security attribute service that are trusted by both the user sign-on service and the name service. The name service will verify the authenticity of the security context information it is passed by verifying that it is originated by or certified by the security services it trusts.

Relevant Threats

Of the threats identified in the previous chapter the following are not directly relevant to, or cannot be addressed at the level of the XFN API Specification:

data store threats arising from security breaches on a name server host
denial of service through physical damage to a name service data store
disclosure or modification through reuse of resources
resource overload other than that arising through the XFN API
denial of service arising from network damage or congestion
disclosure by deduction, for example traffic analysis
tampering with Communications Service Configuration
eavesdropping on communications traffic
substitution of name service programs or dynamic linked libraries
incomplete binding and attribute management operations.

Even though these threats are not directly relevant to the XFN specification itself they are of relevance to name service implementations and could be included in any guidance to implementors.

The threats that are directly relevant in the context of the XFN API itself are:

masquerade as a communications partner
message insertion or modification
repudiation
masquerade of a user principal
exercise of unauthorised authority
abuse of authorised access
resource overload via the XFN API
non-availability of name server.

Current Security Provisions within XFN API

The XFN API includes the following statements regarding security:

XFN does not define a security model nor a common security interface for contexts. Security-related operations, such as those required for authentication or access control, fall into the category of administrative interfaces which are expected to differ widely amongst federation members. Any single choice of security model at the XFN layer is prone to be fundamentally incompatible with the security provided by other direct interfaces, thereby giving rise to inconsistent protection that is susceptible to compromise. Consequently, the security administration interface is kept entirely separate from the federated naming service interface, outside the scope of XFN.

The XFN does, however, provide means by which security can be integrated with specific XFN implementations. Operations that fail due to security-related problems can indicate in the status code the nature of the failure.

Authentication

Authentication is handled in the modules that implement the service interfaces for each particular member naming system. It occurs as part of the communication that occurs between the client and the naming service. Significant engineering issues remain when multiple security mechanisms and administrative domains are involved. These problems can be addressed on a one-to-one basis, or via a general federated security model, outside the scope of XFN. XFN provides the status code [FN_E_AUTHENTICATION_FAILURE] to indicate that an operation failed due to authentication errors.

Access Control

Given the ability to authenticate the principal making a service request, a context service provider must then decide whether this principal should be granted or denied the request. Access control is to be handled through additional interfaces in the specific contexts. This can be done by having operations that control default authorisation at context creation and binding creation times, and having interfaces that modify the current authorisation settings. This is analogous to the umask and chmod scheme for POSIX.1 files.

The access control model is outside the scope of XFN.

XFN provides the status codes [FN_E_CTX_NO_PERMISSION] and [FN_E_ATTR_NO_PERMISSION] to indicate that an operation failed due to access control errors. In the case that the principal is not authorised to know that access has been denied due to permission problems, the status code [FN_E_NAME_NOT_FOUND] or [FN_E_NO_SUCH_ATTRIBUTE] is returned.

As indicated in the previous chapter, this Study generally concurs with the above approach. A name service may support anonymous client principals, or exercise access control at the levels of an enterprise, organisational unit, or individual. It is necessary for an implementation of the XFN or underlying name services to be able to retrieve and propagate any necessary authentication and security attribute information to support the particular access control policies enforced by a name service but it is not necessary to supply or manipulate such information via the XFN API. See Potential Impact on XFN API for an expansion of the potential impact of security on the XFN API.

It should be noted in the guidelines on implementation that there is an implicit assumption that the context implementations are able to retrieve appropriate authentication credentials from the processing environment of the client application. This may be via operating system process attributes or retrieval from a suitably protected credential cache perhaps combined with the invocation of appropriate distributed security services.

Any further discussion on this point would result in a general dissertion on distributed system security services for which the reader is referred to the XDSF.

The XFN specification includes the following measures to address the non-availability of services:

a status return FN_E_INSUFFICIENT_RESOURCES may be returned by XFN functions. This can be used both for actual resource exhaustion and also if an implementation enforces a request quota system
an XFN reference includes the provision for multiple addresses thus supporting the use of replicated services.

Potential Impact on XFN API

The services offered by XFN API may be categorised as:

Information Retrieval
Information retrieval services include name resolution and attribute enquiry.
The principal concerns with these services are availability and the integrity of the returned information. Availability is an issue for the implementation of an XFN service. The integrity of the information returned requires the authentication of the name server providing the information to the client.
The XFN API already includes accommodation for issues of service availability through the capability to support multiple addresses in a XFN object reference thereby supporting replication of services.
The XFN API supports the concept of authoritive contexts but this is with emphasis on the time currency of cached name resolution information rather than its authenticity in terms of origin and integrity. Proposals are detailed in the next chapter to also accommodate authenticity of name resolution information in the XFN API.
Name and Object Binding Management
These include the operations of creating, deleting, and modifying a binding (renaming).
The principle concerns with these services is the maintenance of the integrity of the binding information.
Protection of the integrity of the binding information requires the enforcement of an access control service based upon authentication of the client and verification of appropriate authorities (or privileges) in the context of the specific name service. The authorities required will vary according to the name system being manipulated.
A further concern is the atomicity of the binding operation. The atomicity of the XFN operations is dependent upon the atomicity of the underlying name service operations. An appropriate conformance requirement is to require an implementator of a context implementation to state which XFN operations are atomic or not when invoked over the context implementation.
Binding operations are potentially security significant events and as such should result in the generation of an audit event. This is discussed further in the next chapter.
An additional security policy concern may be constraints on the re-use or re-assignment of names to different objects. This may have particular impact on the historical analysis of security audit trails for which the binding information has to be preserved as well operational impacts. Proposals are included in the next chapter to accommodate the impact of name re-use policies on the XFN API.
Attribute Management
These include adding, modifying, and deleting attributes. In the case where the name service maintains the attributes in association with the name, the name service enforces access control policy.
In the case when the attributes are maintained with the object named by the naming service, the object management service enforces the access control policy and the name service may have to operate with delegated authority from the original requesting principal.
Attribute management operations are potentially security significant events and as such should result in the generation of an audit event. This is discussed further in the next chapter. No other changes to the XFN API are thought necessary to accommodate attribute management access control policy enforcement.
XFN Policies - Access Control Extension
XFN identifies some particular common namespaces, namely enterprise, organisational units, hosts, users, file system and services and presents some naming conventions for these.
As a discussion point it may be appropriate to identify common access policies for these and define specific XFN Authorities to exercise sets of XFN functions for each of the XFN policy namespaces. As an example, the current work on account management within the Security Program Group proposes the following example set of authorities for the user name space:
- XSSO_USER_ADMIN
  Required to create and delete user accounts.
- XSSO_USER_AUDITOR
  Required to modify user account audit service attributes.
- XSSO_USER_SECURITY
  Required to modify user account credentials and to enable and disable user accounts.
- XSSO_USER_ATTRIBUTES
  Required to modify user account attributes that are not controlled by XSSO_USER_AUDITOR or XSS_USER_SECURITY authorities.
- XSSO_ATTRIBUTE_ADMIN
  Required to manage the attribute set applicable to the user name space. That is, create or delete new attributes, assign the requisite authorisation for their assignment to users.

Potential Impact on XFN Protocol

XFN defines two XFN export protocols, one based on DCE and the other based on ONC. DCE RPC by definition operates over communication services that incorporate distributed security services that provide support for authentication and message integrity and confidentiality services. ONC RPC can be used with a number of authentication flavours. An ONC RPC authentication flavour based on the GSS-API over a Kerberos mechanism is available and is being discussed within the IETF currently for standardisation. This ONC RPC authentication flavour provides equivalent support for authentication and message integrity and confidentiality services.

The use of such services is implemented below the RPC interface seen by applications and no change is required to the XFN RPC protocol to specifically address the use of these security services. This is illustrated in Security and XFN Protocol .

Figure: Security and XFN Protocol

The specification should include reference to these security services within the guidelines to implementors.

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