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.
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.
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:
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 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.
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
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:
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.
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.
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 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:
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
The specification should include reference to these security services
within the guidelines to implementors.