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:
-
A status code
FN_E_INTEGRITY_FAILURE could be returned if a name resolution
integrity failure is detected when such a check is required by policy
for all, or some, of the name services invoked to resolve a composite
name.
-
A status code FN_E_NO_INTEGRITY_CHECK could be returned if client
policy requires name resolution integrity checks but one or more of the
name services involved in a name resolution process does not support
such services.
-
The authoritive parameter could be extended, or a
integrity_check parameter added to the
fn_ctx_handle_from_initial()
and
fn_ctx_handle_from_ref()
functions to enable a caller to control the requirement for name
resolution integrity checks for operations using the context handle
returned.
- Note:
- The proposed extensions to DNS provide for data origin authentication
and integrity. See reference
DNSSEC.
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.