Previous section.

Technical Study: Security in Federated Naming

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

Proposed Enhancements to XFN

Name Resolution Integrity

A principal security concern of a name resolution service is the integrity of the name to object binding information returned from a name server. This requirement can be addressed by the incorporation of message origin authentication and message integrity services by a name server implementation. An example of both services is the inclusion of digital signatures with all name resolution responses by a name server. A name service client can verify both the origin and the integrity of the response by verifying the digital signature.

The availability of message origin authentication and message integrity services to a client depends upon their implementation by a name server, and not all name servers will offer this service. Whether message origin authentication and message integrity services are actually used to verify the integrity of name resolution responses is at the option of the name service client. A requirement to use these services could be configured by an installation as enterprise policy, or it could be provided as a caller option.

Integrity is associated to the concept of authoritive information which is already incorporated into the fn_ctx_handle_from_initial() and fn_ctx_handle_from_ref() functions as a caller controlled option. However, the concept of authoritive information as currently expressed in XFN is more concerned with time currency than authenticity. Currency of information and authenticity are different aspects of integrity. A client may be concerned with the authenticity of the information it uses independently of its currency. Techniques such as digital signatures mean that the authenticity of cached information may be verified, however old it is. If verification of currency is required then a time stamp could be incorporated in the reference returned and included in the data under the digital signature.

XFN works above other name services. XFN cannot therefore enforce a requirement for message origin authentication and message integrity on name services that do not support it. However, it should support the use of such services when they are available and ensure that its own XFN protocols include such services.

The following suggestions are made to promote discussion:

Name Re-use and Re-assignment Policies

As previously indicated policy constraining the reuse or re-assignment of names may be imposed within some name services. Such a policy would have an impact on the specification of the fn_ctx_bindfn_ctx_bind(), fn_attr_bindfn_attr_bind(), fn_ctx_unbindfn_ctx_unbind(), fn_ctx_renamefn_ctx_rename(), fn_ctx_create_subcontextfn_ctx_create_subcontext(), fn_attr_create_subcontext() and fn_ctx_destroy_subcontext() functions.

A policy restricting the re-use or re-assignment of names may result in the functions performing bind or subcontext creation operations may fail because of a previous use of the name or because the re-assignment of the name is not permitted. This failure condition could be represented by an additional status code such as FN_E_NO-REUSE.

A name service implementing a name re-use or re-assignment policy could implement an unbind or destroy subcontext operation as a hide binding or subcontext operation. This changes the state of a binding so that it is ignored by normal name resolution requests. Facilities to manage such hidden bindings may need to be provided with the XFN API. Hidden bindings may need to be included in specific name resolution requests to satisfy historical audit analysis. Under specific authorisation hidden bindings may need to be deleted or archived. Such facilities may be supported by providing a separate set of functions, or including an additional parameter within existing functions, or using existing functions with a name service specific authorisation associated with the caller acting as a trigger for the specialised behaviour.

Audit of Name Service Operations

Some name service operations may be considered to be potentially security relevant and as such should result in the generation of an audit event that is submitted to a security audit service. All bind and attribute management functions would be included in this category. These would normally be audited by the name server servicing the request. It is a discussion point as to whether the XFN specification should require an XFN client to also audit such requests and their outcome.

Security relevant events within an XFN client that should require auditing are name resolution failures because of integrity failures and non-availability of service.

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