Previous section.
DCE 1.1: Authentication and Security Services
Copyright © 1997 The Open Group
Introduction to Security Services
This chapter provides an overall introduction to the security services
supported.
Generalities on Security-The Architecture of Trust
supplies some general background information on security,
in an analytic top-down fashion.
DCE Security Model
supplies an encompassing security model for DCE.
The remaining sections of this chapter supply
information on the specific security features supported by DCE,
in a synthetic bottom-up fashion. Thus, this chapter as a whole
gives the reader an overall understanding of how his/her intuitive
concepts of security are supported by DCE.
The remaining chapters discuss the detailed descriptions,
specifications and interfaces (both RPC interoperability
interfaces and API portability interfaces) of all the supported
DCE security features.
Generalities on Security-The Architecture of Trust
The goal of this section is to introduce terminology, within the
context of explicating the concepts that computer users ("should") have in
mind when they think about "(distributed) computer security from first
principles". Although a technical orientation is taken, this
explication is an intuitive and informal discussion of the
philosophy and psychology of security-as distinguished
from a formal or rigorous model of the logic and mathematics
of security.
Thus, to this extent at least, this section is largely informative,
and not normative.
Nevertheless, the inclusion of a section on generalities like this is
considered important (even necessary) here, for several reasons:
-
Computer security as an academic discipline has not yet penetrated the
engineering curriculum to the point where it can be assumed as common
background for the audience of DCE (producers and consumers of
products based upon it).
-
The current security literature is too voluminous and complex to admit
an adequate appraisal of all of its technical aspects here-and
yet there does not seem to exist a convenient summary meeting the
requirements that can be cited.
(The interested reader is encouraged to consult the literature;
the reader already familiar with this material may skim this
section, but should not skip it altogether because of the terminology
introduced.)
-
The various models and terminology sets that exist in the current
literature differ from one another to various extents, and despite some
general agreement on certain overall principles, many details have not yet
reached final form.
It would thus be inappropriate for this specification to
be expressed in a way that favours a single one of those
models. An intuitive approach as presented in this section,
admitting mappings to various such models, best satisfies the needs of
this specification.
-
At the deepest levels, some scepticism continues to be expressed
about the very efficacy and viability of the more abstract
attempts to "finalise" security theory, especially formal models
and the ability to verify implementations of such models.
For example, no completely satisfactory model of even so basic a notion
as "identity" has yet been given.
Indeed, it has been seriously suggested that the shortcomings of
attempted abstractions indicate there is no single "Platonic
form" of security (even theoretically), but rather several
concepts of security that bear only a "family resemblance" to
one another.
-
Ultimately, it is imperative to come to a "human" understanding
(for example, an intuitively appealing "programmer's model")
of the meaning of security, precisely because the problems it attempts to
solve are explicitly human ones (as opposed to technological ones,
see below), and are consequently not completely self-evident.
It can be concluded that (at least currently) some intuition
is not captured by, and the intuition is therefore more reliable than,
"rigorous" definitions of security (if such exist)-certainly so
for the casual user-and this justifies the limited goal of this
section: merely to explicate this intuition. As stated above, since an
appropriate treatment of the basic intuitive content of computer
security along these lines does not seem to be readily available, it is
therefore necessary to provide one here.
As the discussion thus far shows, in the present state of information
technology definitive understanding of many of the problems
of computer security is lacking, much less their solutions (though as
this specification shows, there are some adequate solutions
for some of the problems that are understood).
Security is unique in this respect, in that other areas of computer
technology are circumscribed by relatively limited technological
parameters, whereas security must take into account the unlimited
ingenuity of skillful and determined human attackers having the
full range of computer (and other) tools at their disposal. This
dichotomy is justified and rationalised by the costs required to
reduce to acceptable levels the risks to correct system behaviour from
various threats: the risks from (non-human) benign glitches
(for example, bugs, equipment failure, natural disaster) can often be
held to very low levels by comparatively simple and cheap
engineering practices, but the risks from (human) malicious
attacks can usually be held to acceptably low levels only by
instituting more complex and expensive countermeasures.
Therefore the security services supported by this specification must be
viewed as indicative of only one possible state of the (security) art.
In particular, the fitness of the facilities described here for the
security requirements of a given installed environment relies on
specialised evaluation processes beyond the scope of this
specification, especially the way that these facilities interact with
security facilities provided by other system components (such as hardware,
OSs, user guidelines and administrative policies).
Finally, it is to be noted that nothing currently specified in this
revision of this specification is intended to preclude future enhancements
as they become socially acceptable, technically viable and
commercially available.
Security Attributes: Authenticity, Integrity, Confidentiality
The overall goal of security is to prevent the (human)
misuse (either illicit use altogether, or licit-but-irresponsible
use) of resources-or, failing prevention, to at least detect
misuse and recover from it. This definition is to be interpreted
broadly (for example, it includes such "misuses" as
illicit repudiation).
Proper usage is to be allowed, of course, but it is the
essentially negative nature of the "prevent misuse" clause that
signals why security is so difficult to achieve in practice: namely,
anticipating and defending against all possible misuses is an
essentially open-ended challenge-it's hard to prove that "bad
things didn't happen".
Translating this goal into the language of information technology, it
can be said that computer security attempts to protect the security
attributes (to be specified below) of computer resources,
especially information (data)-that is, to preserve these attributes
as invariants. The word "protect" is used here in a primitive,
undefined (but intuitively appealing) sense. Resources whose security
attributes are "adequately" protected are said to be
secure; otherwise, they are said to be (potentially)
compromised or insecure.
In DCE, the resources to be protected further exist in a
distributed environment; that is, one in which the notion of
communication is an explicit model primitive-in particular
"data-in-communication" ("on-the-wire") is equally as important as
static data (in memory, or in storage media) itself.
The specific "security attributes" (in an intuitive sense, as always
throughout this section) to be protected must support the stated goal of
preventing misuse of resources. To this end, the ones currently
supported in the DCE security model are the following:
-
Authenticity
The state of genuinely representing reality, in an extrinsic sense;
that is, of being correct (actually representing that which is
alleged to be represented), especially of data originating at a
definitive, authoritative source.
-
Integrity
The state of being in an unimpaired condition, in an intrinsic sense;
that is, of being sound and whole, especially of being unmodified (either
in their place of residence, or in transit).
-
Confidentiality
The state of controlled accessibility; that is, of being accessible
to only a designated few; of being known to only a limited few
(privacy or secrecy).
To a first order of approximation, and focusing only on communications
traffic, one can think of preserving "authenticity" to mean being
certain of the identity of the peer communicating entity; preserving
"integrity" to mean protection against (undetectable) writes
(either in-place or active wiretapping); and preserving
"confidentiality (privacy)" to mean protection against
reads (either in-place or passive wiretapping).
Security attributes other than those listed above are sometimes
contemplated-for example, assured service (the state of being
available and obtainable for use when needed; its opposite is known as
denial of service)-but these are currently only peripherally
(that is, other than access control via ACLs, see below) within the scope
of DCE (though they are typically supported by certain
implementation and administrative practices associated with DCE,
such as partitioning, replication, backup and restore). On the other
hand, some other attributes (for example, qualitative or intangible
attributes, such as accuracy, timeliness and reliability) are commonly
considered to be ineligible as security attributes, on the basis
that they cannot be protected from misuse directly (and are better
protected indirectly by other security attributes such as those above),
or are beyond the reach of current computer security technology.
Policy versus Service versus Mechanism
The notion of security policy refers to a set of high-level
requirements or rules an "organisation" places on the security
attributes of its assets (often independently of the use of computers).
Security services refer to the tools (computer and otherwise)
available to the organisation for enforcing such policies, and
security mechanisms refer to the lowest-level technology used to
implement security services. A security domain (or realm)
is the scope of a particular security policy. Since organisations often
exist in hierarchical or other relationships (in the degenerate case
they consist of just a single individual), the condition of overlapping
security domains is potentially an important one (for example, site security
officer may require every department's policies to be subservient to the
site's, in some sense).
As an example of policies, security policies that allow or require individual
members of an organisation to protect the data they "own" are said to be
discretionary; policies that mandate organisational, not
individual users', control are said to be mandatory.
As an example of services, services for controlling access of
"subjects" to "objects" (see
Subjects and Objects, Privilege and Authorisation
)
can be identity-based (that is, "who"-criteria such
as individual identity and group membership), or rule-based
(for example, "what"-criteria such as clearance of
subject and sensitivity of object, "when"-criteria such
as time-of-day restrictions, and "where"-criteria, such as
the hosts on which programs reside).
As an example of mechanisms: cryptographic algorithms (see below) can be
based on symmetric or asymmetric key technology.
Various types of security services and mechanisms, or combinations of
them, may (or may not) be suitable for protecting an organisation's
resources, depending on the security policy the organisation has adopted
(for example, discretionary policies are often supported by
identity-based services, and mandatory policies are often supported
by rule-based services).
This specification supports computer security services (and the
mechanisms necessary to implement them) that can be used by
organisations in a variety of ways, to support in whole or in part many
different security policies. But it is always the responsibility
of the organisation to evaluate the adequacy of this specification's
(or any
other) security services and mechanisms for supporting its specific
policies. Such an evaluation will normally be based on a threat
analysis, but a discussion of that topic is beyond the scope of this
specification.
Subjects and Objects, Privilege and Authorisation
In the security sense, the term object is used to refer to "the
passive aspect of" entities (or resources, for example, data)
whose security attributes are to be protected, and subject
or principal refers to "the active aspect of" entities
(for example, people or computer processes) that interact with objects.
Subjects are also considered to be objects insofar as they have
security attributes that need to be protected.
Subjects are sometimes further classified into
initiators (those subjects that initiate interaction with objects,
and are accountable for the interaction) and intermediaries or
delegates (intermediates that merely assist a
principal in an interaction but are not responsible for initiating it).
This distinction is typically only important in a distributed
environment, because the initiator/delegate relationship is typically
established by subjects communicating with one another.
(Note that DCE supports delegation in this revision.)
In the security sense, the term access refers to the interaction
(mentioned above) of a subject with an object, the possible types of
access in a system being classified into types or classes called
access modes (for example, read or write a file,
signal or communicate with a process, execute on a
processor). The specific instances of access modes that a specific
subject has been granted (as opposed to denied) to a
specific object are called the subject's access permissions (or
rights) to the object. A subject that has been granted privilege
to access an object in a specified mode is said to be authorised
to access the object in that mode.
The abstract matrix (which is primarily conceptual, not
actually realised by a single monolithic data structure in
implementations) whose rows are parameterised by subjects and
whose columns are parameterised by objects, and whose entries
consist of the permissions that the subjects have to the objects,
is called the access matrix of the security system.
A row of the access matrix (that is, the "subject-side"
or "client-side access information that a single subject
has to all objects) is called the privilege information
(or vector) or capability list associated with the subject.
A column of the access matrix (that is, the "object-side" or
"server-side" access information that all subjects have to a
single object) is called the control information (or vector) or
authorisation list or access control list (ACL)
associated with the object.
Note that there do exist entities other than subjects and
objects in computer systems; for example, hardware and OSs. (No special
name is reserved for these, other than simply "(computing) entities".)
Such entities do not figure into the access matrix (alternatively, such
entities as hardware and OSs may be inserted into the access matrix
with "infinite privileges"), but they obviously have a part to play in
the security of systems. Much of what is said here about subjects and
objects applies with appropriate modification of detail (in the usual
intuitive sense appealed to throughout this section) to these entities
-and this understanding is assumed throughout this specification
unless explicitly stated otherwise.
Knowledge versus Belief; Trust
Subjects cannot always have absolute knowledge (in the sense of
logical provability) of the true status of security attributes of
objects. Instead, they must often rely on relative belief (based on a
variety of considerations, evoking various levels of confidence or
assurance) about their status-and they are then entitled
and expected to act "as if" their belief were knowledge.
Belief is often a subjective matter and can be based on
such qualitative criteria as "climate of opinion" (for example,
"everybody bgcolor="#FFFFFF" `knows' DES is `pretty safe''') or "assessment of personal
character (of individual humans)", but there does exist at least one
objective criterion that is universally accepted as an appropriate
standard on which to base belief, and that is mathematical
probability (and its concomitant, computational complexity).
This is best illustrated by an example. Users are usually justified in
believing that their password (which is a piece of protectable data, and
is therefore an object in the security sense), if well-chosen, is secure
(in particular, its confidentiality attribute is protected), because the
probability of someone's guessing it is acceptably low. But if the user
discovers their password written on a scrap of paper in a wastebasket,
they are justified in believing (and acting "as if") it has been
compromised-that is, even if they do not know with certainty that
a miscreant intends to illicitly access their account, the probability
of that event is now unacceptably high.
Of course, the actual values of "low" and "high" probability,
and the recovery procedures to be taken upon suspicion
of compromise, are matters of security policy.
A subject is said to trust an object (or a subject, or other
entity such as hardware or OS) if it believes the object is secure.
That is, subject A trusts object B if A believes B's
security attributes such as authenticity, integrity and confidentiality
have not been compromised. If case B is a subject (or other active
entity, such as hardware or OS), this is often paraphrased by saying
"A trusts B if A believes B behaves correctly
(that is, the way B is specified to behave)", though this
paraphrase focuses only on the attribute of authenticity.
As conceived of here, "trust" cannot be created; it can
only be posited (a priori) of an entity, and
then transferred to other entities ("chains" of trust)-see
Untrusted Environments: A Priori Trust and Trust Chains
.
Untrusted Environments: A Priori Trust and Trust Chains
It is the classical position of computer security to take a conservative
(or "fail-safe") stance; that is, to council a subject to believe its
environment to be untrustworthy unless it can be convinced to believe
otherwise. The accepted technique for this is to "bootstrap" the
trusted environment: introduce a minimal number of "small" (that is,
easily protectable) a priori trusted entities to serve
as the foundation upon which a layer of more and "larger" (that is,
harder to protect) trusted objects can be established (by trusted
means, especially by logically sound arguments), and continue in this
way to build up (trust) chains of trusted entities (also
called indirect or transitive trust), resulting in an
overarching trusted environment (= set of trusted objects).
These a priori trusted entities can take many forms, and go by many
names, for example:
-
Self
Every subject is assumed to trust itself (self-deception is
beyond the scope of most security models).
-
Physical Security
A secure entity to which no attacker can gain access can be trusted to
remain secure from external attack. (This does not address the question
of internal security, however; for example, malicious code.)
-
Trusted Computing Base (TCB)
The fundamental core set of hardware and software that must be trusted
a priori (for example, local machine hardware and OS).
(As usual in this section, this definition does not purport to be
rigorous, but its intuitive import is clear enough: "All the computer
stuff that is relevant to supporting security policy".)
-
Reference Monitor
A trusted subject (or entity) that mediates all access to a protected
object.
Indeed, the reference monitor is considered to embody bgcolor="#FFFFFF" the
protection of the object.
-
Trusted Algorithm or Protocol
An algorithm or protocol whose efficacy is trusted-in particular,
cryptographic algorithms (see below), and, in a distributed environment,
cryptographic protocols (a "protocol" is simply a distributed
algorithm; that is, one in which communication is an explicit
primitive operation).
-
Secrets
The "smallest" (in the sense of "easiest to protect") objects, whose
security is considered tantamount to the security of "larger"
(in the sense of "harder to protect") objects, by means of trust
chains (see discussion below on key-based security).
-
Authority (Trusted Third Party)
An entity which is trusted to know the secrets of objects other than itself.
A typical responsibility for an authority is to certify objects;
that is, to vouch for their security. For example, consider a
credential, which is a data element (an object) containing
security information (say, privilege information) about a
subject, say A. Suppose A presents its
(purported) credential to another subject, B, which acts as a
reference monitor for the object to which A desires access. In order
for B to make an informed access decision, it needs to be convinced of
the credential's security (otherwise, it should make the default
"fail-safe" decision to deny access).
But if A is trusted by an authority, say X, which B trusts,
and if X has certified the credential (thereby turning
it into a certificate (or token, or ticket),
and so on), then B is justified in granting
or denying access on the basis of the (now trusted) credential.
Distributed Security: Secrets and Cryptology
A certain amount of physical security is a necessary element of
a priori trust in all environments, and may even (depending on
security policy) be sufficient for all the security of some suitable
environments (for example, of standalone machines, or of machines and the
network itself in small local area networks). But physical security by
itself is usually an incomplete solution even within a single physical
security domain (because there usually exist threats from sources other
than ones related to physical access), and is certainly inadequate in an
environment of geographically dispersed distributed systems (such as
those contemplated by DCE) that span multiple physical security
domains. So, physical security is almost always supplemented with
logical security (security based on non-material entities).
Indeed, the single most important tool for building trust chains,
especially in a distributed environment, is an entity of logical
security, namely the concept of secrets.
The idea is that if a subject A can
demonstrate (via a trusted protocol in the distributed environment) to
another subject B that it knows a (secure) secret, then B is
justified in believing A itself is secure. This "link" in the
"chain" of trusted subjects, from a "small" object like a secret to
a "large" object like a subject (and the objects it acts as reference
monitor for), effects the "bootstrapping" mentioned above. In this
way, the seemingly intractable problem of the security of a complex
system as a whole is reduced to the more tractable problem of the
security of a small subset of the system: its secrets ("Kerckhoffs'
Doctrine").
The science of using secrets to implement security mechanisms is called
cryptography, and the art of analysing cryptographic mechanisms for
the purpose of (potentially) compromising systems based on them is
called cryptanalysis; the two together go under the combined name of
cryptology. Of course, these ideas predate the use of computers;
using secrets for security purposes was implemented already for military
purposes in prehistoric antiquity, where messages relayed by courier
figured in early "distributed systems".
Encoding/Decoding and Encryption/Decryption of Messages
Secrets are particularly effective in protecting the security of
messages; that is, "data-in-communication".
A primitive way to do this is by the mechanism of encoding/decoding.
By prearrangement, two subjects agree that a specified message is
to be semantically represented (encoded)
by a specified utterance-the actual mapping between message and
utterance (the so-called codebook) is kept secret between the two
subjects. For example, "The moon is full" might be mapped to "Drop the
bomb at midnight". While this mechanism in its purest form is rather
secure, it is rigid (it's hard to communicate concepts not in
the prearranged codebook), and it's difficult to implement securely (the
codebook is difficult to protect).
By making use of syntax instead of semantics (via alphabetic
writing), a mechanism flexible enough to effectively support the
security of arbitrary messages, called encryption/decryption or
encipherment/decipherment, becomes available. The message to be
communicated is first (non-secretly) represented in a well-known
alphabetic representation (for example, first express the message in
English, then spell it using the symbols for, say, lower-case letters,
digits, space and period-an alphabet of 38 characters),
then the resulting representation is "scrambled" (encrypted
or enciphered) by some secret (or secret-based) technique
prearranged between the communicating subjects.
For example, the scrambling algorithm might consist of a specified
combination of substitutions (whereby each symbol is replaced
by another predetermined one, possibly from another alphabet;
for example, "a" is replaced by "alpha", "b" by
"ß", and so on), and transpositions (permutations)
(whereby each symbol of the message is interchanged with another
symbol of the message; for example, each symbol is interchanged in
pairs with its neighbour).
The receiving subject decrypts (or deciphers) the received
cryptotext (ciphertext) by an inverse technique, thereby
recovering the original plaintext (cleartext) message.
With the advent of digital computers, the principles of
encryption/decryption not only remain valid (the plaintext alphabet
consisting now of binary bit-representations, say ASCII), but have been
raised to new levels of sophistication because of the raw power of
computers for both cryptographic and cryptanalytic purposes. A new
"golden age" of cryptology has, in fact, arisen precisely because of the
"digital (computer) age"-and due to this, the field is
changing rapidly at the present time.
Key-based Security: Kerckhoffs' Doctrine
As discussed above, the security of (secret-based) communications can be
reduced to the security of the secrets driving the encryption/decryption
mechanisms. A further refinement of this idea is to require to be
kept secret, not the entire algorithm used for
encryption/decryption, but only a small (that is, even easier to protect)
part of it, namely, a parameter to the algorithm.
Such a secret parameter is called a cryptovariable or
key (in analogy with "locks and keys", not "database query keys"
-the terminology predates computers).
This idea is called Kerckhoffs' Doctrine
(in honour of the pioneering 19th century cryptologist Auguste
Kerckhoffs, who first articulated it), and is usually paraphrased as:
-
-
SECURITY RESIDES SOLELY IN THE KEYS
and not, for example, in such qualities as attackers' ignorance
of the cryptoalgorithms themselves (the latter is humourously known as
"security by obscurity").
By this means, the security of the encryption/decryption mechanism is
decomposed into two components:
-
The strength of the underlying (non-secret) algorithm
(that is, its resistance to cryptanalysis that may
compromise the contents of encrypted messages to an attacker not
initially knowing the key)
-
The secrecy of the key itself
Extended to distributed security, Kerckhoffs' Doctrine continues
to assume that distributed security must reside solely in the keys,
even if the attacker knows the cryptographic protocols in use,
and has completely "compromised the network"; that is, has the unlimited
ability to intercept and modify all data-in-communication.
In this manner, the infrastructure of secrecy-based secure
communication mechanisms is reduced to just three elements
(which must be scrutinised both individually and in combination for
their adequacy in supporting the chosen security policy):
-
Strong cryptographic algorithms
-
Key management-creation, storage, distribution, use
and destruction of the keys themselves
-
Secure protocols (the new element introduced by distribution)
DCE security, in common with all practical contemporary distributed
computer-based security, is based on these elements (see the discussion
of tickets, in
DCE Security Model
).
Outline of the Remainder of this Chapter, and of this Specification
The presentation of this chapter is now shifted from generalities
("general security theory independent of DCE") to specifics
("specific services and mechanisms supported by DCE").
To that end, the remaining sections of this chapter proceed as follows:
- Note:
-
It is anticipated that future versions of DCE will support
additional security features-for example,
auditing,
alternate cryptographic algorithms (especially, asymmetric key
technology), alternate authentication and privilege services, and so on.
DCE Security Model
This section forms a bridge between the generalities of
Generalities on Security-The Architecture of Trust
,
and the specifics of the following sections. It introduces the
basic DCE security model; that is, the architecture or framework
into which the various DCE security services and facilities may fit.
This section just gives a "once over lightly" treatment-all
terminology and details not properly introduced in this section are
discussed fully in the following sections and chapters.
The security model is depicted in
DCE Security Model
,
which shows as its focal element an application Client (source of an
RPC) interacting with an application Server (target of an RPC) in a
DCE environment.
Figure: DCE Security Model
From the point of view of communications (RPC), the client and
server are communicating entities, with the server acting as the
Resource Manager for the resources (objects) under
its control-that is, the client invokes a remote procedure call,
which is executed by the server, acting on its resources. From the
point of view of security, the client and server are
subjects, and the server acts as a Reference Monitor for its
(protected) objects; that is, the ultimate arbiter for access by
clients to the objects.
The application server is responsible for associating an ACL to every
object it wishes to protect. The exact definition of what is an
"object" (or "resource") is entirely at the discretion of the
server; that is, it is application-dependent. As examples, an object could
be an item of stored data (such as a file), or could be a purely
computational operation (such as matrix inversion). Said another way,
by its choice of the things it attaches ACLs to, the server
defines what its (protected) objects are. Note that even if the
ACLs are actually physically stored separately from the objects they
protect (that is, in an "ACL server"), DCE recognises them as
being within the same security domain as the objects and the object
server-intuitively stated, "the ACLs cannot be more secure than
the objects or the object server (reference monitor)". ACL
Editors are programs that directly manipulate servers' ACLs (without
actually accessing the objects protected by those ACLs). (ACL Editors
that support a user interface, enabling end-users such as the
"owners" of objects to interactively manage the ACLs on objects, are
called ACL Editing Commands-these are not specified in
this specification.)
The security environment in which such client/server access happens
has three services-implemented as RPC servers-at its core:
-
Registration Service (RS), or Registry Service, or
simply The Registry (Rgy)
-
Key Distribution Service (KDS), or Authentication
Service/Ticket-granting Service (AS+TGS)
-
Privilege Service (PS), or Privilege-ticket-granting Service
(PTGS).
These three services are trusted third parties in the DCE
security model, and they form part of the DCE Trusted Computing
Base (TCB)-also called the network TCB, for short.
These three services are thus entrusted to know the secrets of subjects
and other security information, and to implement the mechanisms for
enforcing security policies.
Their security must therefore not be compromised, and
in an installed site they must run on secure computers
(consistent with the organisation's security policy; for example,
physically secure machines running secure OSs under the administration
of a security officer).
The RS, KDS and PS are actually distributed, partitioned (and
potentially replicated) services, with the unit of partition being the
cell (that is, for security purposes, an instance of the
RS/KDS/PS triple). The cell in whose RS datastore the security
information for a given principal is held is called the home cell
of the principal. In a multiple-cell environment, the various RS, KDS
and PS services participate in an inter-cell (or cross-cell)
coordination, to provide logically unitary services (that is, to
create the effect of a multi-cell DCE TCB).
In this inter-cell coordination, the per-cell RS, KDS and PS servers do
not need to communicate directly with their foreign-cell
counterparts in the performance of their services (they may do so
incidentally, however, for such purposes as parsing stringnames into
their component pieces, or for cross-cell key management).
Intra-cell, the RS, KDS and PS do communicate amongst themselves,
but these communications are not specified in the current version
of this specification. Thus, for example, implementations are not
prevented
from implementing a cell's RS, KDS and PS within a single process
(potentially replicated)-which is then typically known by a
comprehensive name, such as a security server or security
daemon.
Before a principal (either client or server) can participate in the
DCE security environment, it must have a (principal)
identity registered with the RS.
(This registration must initially be "out of band" of the protocols
specified by DCE, in order to guarantee its security. The
intuitive reason for this is that a user's password must be initially
agreed to "by word of mouth" (that is, "out of band") between the user
and the administrator before the system can use the protocols specified
herein to authenticate the user. Furthermore, the initial
administrative principal must also be installed by another "out of
band" process, such as by pre-installing it before initial system
startup.) These identities are represented by both user-friendly
cell and principal (string)names and by their UUIDs
(the ID Map Facility provides correspondences between
these). The RS maintains a datastore of the identities of all
subjects, and long-term secrets (cryptographic keys for the DES
cryptoalgorithm) associated with them. RS Editors (or Registry
Editors) are programs that directly manipulate RS datastores-
typically, RS Editors support an administrative interface,
enabling security administrators to interactively manage the RS
datastore (this is not specified in this document).
Having previously registered their identities with the RS, before a
client and a server can successfully participate in a client/server
session within the DCE security environment, they must
"establish their identities", which can be accomplished only by
"knowing their own secret" (that is, knowing the secret (long-term key)
associated with their identity in the RS datastore). Clients are
typically endowed (by process-hierarchy inheritance) with the identity
of the end-user invoking them, and these end-users establish their
identities by means of the Login Facility (which is
password-driven, for the convenience of interactive human
users). Servers, on the other hand, are typically endowed with an
identity independent of any end-user (for example, a system administrator)
invoking them, and they establish their identities by means of the
Key Management Facility (which is key-driven, for the
convenience of non-interactive servers). In order for the local
TCB to evaluate its trust of the DCE TCB (for such purposes as, for
example, storing its "standalone-machine" user data in the "network"
RS datastore), the local TCB must itself be a principal (the host
principal, or machine principal)-this is the role
fulfilled by the Security Client Daemon (SCD). The SCD ("host
principal" or "machine principal") can be viewed in some ways as the
security analog of the "host address" communications concept.
At this point, it is convenient to introduce the notions of ticket
and Privilege Attribute Certificate (PAC). Tickets are
(protected) credential certificates, representing the "authenticated
identity" of a client, trusted by a specified server to which they are
targeted (that is, encrypted in the server's long-term key), and
containing a short-term session key, which actually represents the
authentication between the client and the server. Either this session
key, or another one securely negotiated between the client and server,
can function as a conversation key (also known as a subsession
key or true session key); that is, actually used to
cryptographically protect client/server communications.
- Note:
- It is a common practice to use the terms "session key" and "conversation
key" synonymously; indeed, the same key can function as
both, but it is preferable to distinguish between these notions.
PACs are (protected) certificates, specifying the attributes of the
client that the server uses to determine ("grant" or "deny") access
to its protected objects. Tickets that have PACs associated with them
are called privilege-tickets). Non-privilege-tickets are managed
by the KDS, and PACs are managed by the PS; privilege-tickets are
managed by the KDS and PS working together.
All of this scaffolding has its culmination in the Protected RPC
facility. When a client wishes to initiate a session with a
server, it obtains a privilege-ticket targeted to the specified server,
and then RPC service requests and responses between the client and
server are protected (for authenticity, integrity and/or
confidentiality, as agreed upon by the client and server) with the
session key contained in the privilege-ticket or a negotiated
conversation ("true session") key.
When the client's initial RPC service request containing the privilege-ticket
arrives at the server, the server's ACL Manager module
uses the PAC associated with the privilege-ticket and the ACL
attached to the protected object specified by the client, to make an
access control decision; that is, whether to grant or deny access (for the
specific operation specified by the client) to the object in question.
Subsequent RPC service requests need not carry a privilege-ticket-
once the session/conversation key and PAC have been securely established
with the initial service request, they can be used with confidence to
protect subsequent requests until an agreed-upon time-out date,
typically on the order of a couple of hours, is reached (and then they can
be re-established if necessary).
- Note:
- The preceding description has been couched in terms of RPC, because that
is the communications technology specified by DCE.
However, the security technology specified in this specification
is clearly applicable, with appropriate modification of detail, to arbitrary
communications mechanisms. Clients and servers can still participate in
a secure environment (clients protect their PACs, servers protect their
objects with ACLs, and so on), provided a well-defined means is specified for
communicating the necessary messages. However, the only
communications mechanism currently specified in DCE is RPC.
The authentication protocols employed ensure two-way
(mutual, bilateral) authentication between client and
server. That is, they not only "authenticate the client to the server"
(preventing a masquerading attack, whereby the client can gain
access to a server posing as an identity for which it does not know the
secret), but also "authenticate the server to the client" (preventing
a spoofing attack, whereby a counterfeit server-other than the
one designated by the client-can trick the client into believing
it is communicating with the designated server).
- Note:
-
There is a potential "vicious circle" co-dependency of security on
(RPC) communications and vice versa.
This is because the protected RPC architecture requires that certain
metadata (called RPC verifiers) are present in RPC PDUs
(protocol data units), but that metadata is not available until
after the client has communicated with the KDS and PS servers.
This potential problem is averted by the KDS and PS services being
offered over "unprotected" RPC. The security information required by
protected RPC is thereby conveyed as data (cryptographically
protected, to be sure), not metadata.
The resulting dependency graph is thus simplified; protected RPC
depends on security services, which in turn depend (only) on
unprotected RPC (which of course does not depend on security services).
All the servers specified in DCE (RS, KDS, PS, SCD) communicate
via RPC. The KDS and PS use unprotected RPC (their data is protected by
direct cryptographic means, not by protected RPC). The RS and SCD use
protected RPC, with authentication service rpc_c_authn_dce_secret,
of authorisation type rpc_c_authz_dce, and of protection
level rpc_c_protect_level_pkt_integ.
(See the referenced Open Group DCE 1.1 RPC Specification, augmented by this specification, for explanations
of this terminology.)
Message Digests 4 and 5 (MD4, MD5)
Message Digest 4 (MD4) and Message Digest 5 (MD5) are
"non-invertible" ("one-way") functions:
given any message
as input, MD4/5 produces a 128-bit message digest (or hash,
checksum or fingerprint) as output. The critical
cryptographic property claimed by MD4/5 is that they are
collision-resistant (or collision-"proof");
it is very "difficult" (that is, computationally infeasible)
to exhibit distinct messages having the same MD4/5 checksum.
Note that the MD4/5 algorithms are not encryption/decryption
mechanisms (which are invertible functions), and they do not
depend on a cryptographic key. In DCE, MD4/5 checksums are
encrypted with DES to produce keyed cryptographic checksums for purposes
of integrity-protection.
A keyed cryptographic checksum of a message is
called a signature or message integrity code (MIC)
or token for the message.
DCE protects the authenticity and integrity (but not the
confidentiality) attributes of a message by DES-MD4/5 crypto-checksumming
the message; that is, DES-encrypting its MD4/5 checksum using a DES
conversation key known only to the originator and recipient of the
message (and, possibly, other third parties they trust).
(Confidentiality protection is supported by DES-encrypting the whole
message, not just its MD4/5 checksum.)
No interfaces to raw MD4/5 routines are directly supported in DCE.
Instead, MD4/5 are embedded in various DCE protocols as discussed below.
Data Encryption Standard (DES)
The only encryption/decryption algorithm currently supported by DCE
is the Data Encryption Standard (DES), in
Cipher Block Chaining (CBC) Mode.
This algorithm has been in steady use since the late 1970s, and in
that time has received intense scrutiny without revealing
debilitating weaknesses. Hence, it is generally considered to be
"secure" by many commercial users. (Though as always it is
the responsibility of each organisation to determine if DES is secure
enough to satisfy its security policy.)
DES is based on 64-bit keys, of which only 56 bits are "active";
that is, the key is treated as a 64-bit data item, though only 56 bits
actually participate in the cryptographic characteristics of the algorithm.
This means that an exhaustive key search attack would require
O(256) operations, which is currently considered to be
"computationally infeasible" for most commercial (non-military)
applications. Note, however, that the key space may effectively
(depending on the actual implementation) be much smaller in systems that
use human-memorisable secondary keys such as passwords that are
subsequently mapped into DES keys-such keys may therefore be more
susceptible to dictionary attacks (exhaustive "guessing" of all
passwords). Furthermore, the mere size of key spaces is no guarantee
that more efficient (non-exhaustive) attacks do not exist.
The core DES algorithm acts on 64-bit blocks of plaintext and
ciphertext. It is the CBC Mode that specifies how to encrypt/decrypt
messages of length other than 64 bits.
DCE protects the authenticity, integrity and confidentiality
attributes of a message by DES-encrypting it (or, if confidentiality is
not required, encrypting only the message's MD4/5 message digest)
in a DES conversation key known only to the originator and recipient
of the message (and, possibly, third parties they trust).
No API to raw DES routines is directly supported in DCE.
Instead, DES is embedded in various DCE protocols as discussed below.
- Note:
-
There may be restrictions on the use and/or import/export of DES by some
national governments. Future versions of DCE may support other
cryptographic algorithms to support the needs of these and other
organisations.
Kerberos Key Distribution (Authentication) Service (KDS)
The function of the Kerberos Key Distribution Service (KDS) is to
distribute session keys and tickets (certificates, protected
credentials). Session keys are short-term keys
generated on the fly and used to authenticate a client and a
server to one another. Either the session key or a subsequently negotiated
conversation ("true session") key is used to protect
most communications (especially, application-level communications) in the
DCE environment-these are to be distinguished from
the long-term keys associated with principals,
which are held in the RS datastore and used only minimally, namely
to protect internal protocols ("metadata", as opposed to
application-level data), "bootstrapping" the rest of the protected
DCE environment (see the outline below). Stringnames in
tickets represent the "authentication identity" of clients (as
distinguished from their "authorisation identity", which is
represented by UUIDs carried in privilege-tickets-see
Privilege (Authorisation) Service (PS)
).
Tickets are trusted by a specific server to which they are
"targeted", by cryptographically protecting them in the server's
long-term key (or another key the server trusts).
A ticket that is targeted to a KDS server principal (KDS
principals are also called cell principals, because of their
central position in the architecture) is called a
ticket-granting-ticket (TGT); its only use is as a kind of
"metaticket", to be used for authenticating the client to the KDS
server, so that the client can avail itself of the KDS's services (as
seen in the next paragraph, the KDS supports only the
"metaservice" of issuing tickets).
A ticket that is targeted to a non-KDS server (that is, a
non-ticket-granting-ticket) is sometimes called a service-ticket
when it is necessary to emphasise its role in obtaining "useful"
services (as opposed to the "metaservice" of merely obtaining
tickets from the KDS). However, pointedly making a distinction between
ticket-granting-tickets and service-tickets is avoided in this
specification unless it is absolutely necessary.
The KDS offers (exactly) two kinds of services (and because of these two
services, the KDS is also known as the "AS+TGS"):
-
Authentication Service (AS)
Issues initial tickets (either ticket-granting-tickets or
service-tickets), on the basis of unauthenticated requests
(that is, an authenticating ticket is not required by the AS).
-
Ticket-granting Service (TGS)
Issues subsequent (non-initial) tickets
(either ticket-granting-tickets or service-tickets), on the basis
of authenticated requests (that is, an authenticating ticket
is required by the TGS).
By abuse of language, one speaks of these two services as if they were
autonomous entities. Thus, for example, "A sends a message
to the AS" really means "A sends a message to the KDS,
requesting its AS service".
Tickets contain the following information, appropriately protected (the
"names" mentioned here are fully discussed elsewhere in this
specification):
-
Named Client
Stringname of the client principal, represented by its cell name,
and by its per-cell principal name (held in its cell's RS datastore).
-
Targeted Server
Stringname of the server principal, again represented by cell
name and per-cell RS datastore name.
-
Session Key
For protecting communications (or negotiating a subsequent
conversation-"true session"-key to do the actual
protection of communications) between the named client and
targeted server (or indeed, between any two principals that the client
and/or server share the session key with).
-
Lifetime Timestamps
The interval of time for which the ticket-and also the session
key it carries, and the conversation keys derived from it-is to be
honoured. This is represented by a set of timestamps,
primarily consisting of a start time and an expiration
time, but also including an additional authentication time and
absolute expiration time for technical reasons.
-
Transit Path
The ordered sequence of authentication authorities (KDS servers)
that vouch for this ticket, treated as an unordered set.
-
Various other data discussed in detail in
Key Distribution (Authentication) Services
.
Given these concepts, the basic (intra-cell) Kerberos authentication
protocol for authenticating a client A and a server B to one
another is outlined below. This outline, while not an entirely minimal
one, is intended to give only a "working knowledge" of the protocol,
and does not delve into its many intricacies (full details are covered in
Key Distribution (Authentication) Services
).
To this end, the scope of the outlines in this and the following
two sections is to discuss the roles of:
-
Primarily: identities (represented by stringnames in this section,
and/or by UUIDs in
Privilege (Authorisation) Service (PS)
);
session keys (representing the concrete manifestation of the
abstract notion of "authentication"); and tickets (certificates).
Readers encountering Kerberos for the first time are advised to focus
solely on these primary items.
-
Secondarily: (forward and reverse) authenticators
(for client-to-server and server-to-client authentication,
respectively); lifetime timestamps (consisting of a
start timestamp earlier than which the ticket is not to
be honoured for service requests, expiration timestamp later
than which the ticket is not to be honoured for service requests,
and an absolute expiration timestamp later than
which the ticket is not to be renewed by the KDS); authentication
timestamp (determining "freshness" of communications);
nonces (for matching requests and responses); checksums (for
supporting integrity); transit paths; conversation
keys (which are the "true session" keys used for actual protection
of application-level data, as opposed to the metadata of the Kerberos
protocol itself); and authorisation data (which is more properly
introduced in
Privilege (Authorisation) Service (PS)
).
-
Tertiary paraphernalia of the Kerberos protocol, such as
client addresses, options, flags, sequence
numbers, and so on, are not discussed in this chapter at all (see
Key Distribution (Authentication) Services
).
-
Privilege-tickets and the inter-cell authentication protocol are
discussed in
Privilege (Authorisation) Service (PS)
and
Cells-Cross-cell Authentication and Authorisation
.
-
Access control lists (ACLs) and access determination algorithms
are covered in
Access Control Lists (ACLs)
and
ACL Managers, Permissions, Access Determination Algorithms
.
-
Finally, integrating security with RPC is mentioned in
Protected RPC
(but is not analysed at the protocol level until
Protected RPC
).
- Note:
-
The aspect of lifetimes of tickets (and short-term session and
conversation keys) enables the capability of (secure) caching,
which has a profound impact on implementations. Caching is currently
considered to be implementation-dependent and therefore beyond the
scope of this specification, but typical implementations exploit caching
heavily because of the benefits in performance efficiency that it
confers. In particular, a client need obtain a
ticket-granting-ticket to a given cell only when it first needs to
authenticate to a server in that cell (for example, at "login time" in its
home cell), and again whenever it expires or "times out", and then the
client can use it to obtain many other tickets.
Similarly, a client need obtain a service-ticket to a given server only
the first time the server is contacted (and again whenever it times
out), and then the client and server can use the corresponding session
key (or an associated conversation key) many times.
And similarly again, a client's privilege attributes (PAC) need
be obtained by the server only once (and again whenever it times out),
and cached there to be used many times to determine access rights for
many service requests.
Throughout the outlines below, the following (standard) notations are used:
-
A -> B: M
-
A <­ B: M´
"Message" (that is, data) M communicated from A to B
(typically via RPC invocation), followed by message M´
communicated from B to A (typically via RPC return).
Strictly speaking, the notation "A -> B: M"
actually means: "it is the design intent of the protocol that the
message M be sent by A and received by B." And in a
sequence of messages, "it is the design intent that the order of
messages be that specified".
Since the communications environment of cryptographic protocols is one in
which messages may be rerouted, corrupted, maliciously modified,
duplicated, resequenced, delayed, lost, and so on, assurance of any of these
qualities cannot be guaranteed unless it is provided by the protocol
itself.
-
M1, M2
Message consisting of two "parts"
M1 and M2.
(Similarly for messages consisting of more than two parts.)
As befits the high-level intent of this chapter,
this notation is not to be interpreted as carrying low-level
formatting connotations, such as "ordering" or "concatenation" of
the parts M1 and M2.
(However, such formatting issues are covered carefully in the
detailed protocol specifications of later chapters.)
-
{M}K
Message M encrypted with a key K, via some specified
encryption mechanism.
Again in accordance with the high-level intent of this chapter,
this notation is not to be interpreted as carrying low-level
information.
In particular, the "specified encryption mechanism" may encompass
more than a mere "raw" encryption algorithm; that is, higher-level
information such as "confounder" and "built-in-integrity"
information (see
Registered Encryption Types
).
Basic KDS (AS+TGS) Protocol
,
then, is the basic Kerberos authentication protocol, in the
environment of a single cell X.
Figure: Basic KDS (AS+TGS) Protocol
-
A -> AS: A, KDS, LA,KDS,
NA,AS
1 (AS Request: Ask for ticket to KDS.)
A, as a communicating entity, sends an AS Request message to the KDS
server (in X, A's home cell), communicating its (A's)
claimed principal stringname (not UUID), thereby requesting a
(ticket-granting-)ticket (TGT), denoted TktA,KDS,
targeted to the (same) KDS server.
(The principal stringnames are here denoted simply "A"
and "KDS", though in reality they are something like
/.../cellX/clientA and /.../cellX/krbtgt/cellX.
See
Cells-Cross-cell Authentication and Authorisation
and
Integration with Naming Services
).
Included in this request is the desired lifetime LA,KDS
of the ticket TktA,KDS and of the session key
KA,KDS it carries (no ticket is to be honoured whose
lifetime has expired),
and a nonce NA,AS that A will use to
associate this request message with its corresponding response message.
Prior to DCE 1.1,
this communication is unprotected ("in the clear",
"unauthenticated")-in particular, this figure currently
specifies no "pre-authentication"
(whereby A tries to prove to the KDS that it
"really is A", in the sense of knowing the long-term key,
KA, of the principal it claims to be).
Refer to
Third-Party Pre-Authentication Protocol
for the DCE 1.1 (and newer versions) pre-authentication protocol.
-
A <­ AS: A, {KDS, KA,KDS,
LA,KDS, NA,AS}KA,
TktA,KDS
1½ (AS Response: Receive ticket to KDS.)
Upon receiving the AS Request message (allegedly) from A, the KDS
server first generates a "high-quality" (cryptographically random)
secure session key, KA,KDS, to be used in protecting
communications between A and the KDS.
Then the KDS constructs the ticket, TktA,KDS,
naming the claimed principal A and containing the session key
KA,KDS, protecting TktA,KDS with the
long-term key KKDS of the KDS (that is, the ticket
is targeted to the KDS server itself).
Also included in this ticket are the identity of the KDS server to which it
is targeted, and the lifetime LA,KDS (which may be
different from the lifetime requested by A, depending on policy,
though this isn't indicated notationally), and its transit path
PX (which, in this intra-cell case, is merely a
trivial path indicating this cell X only):
-
-
TktA,KDS = KDS,
{A, KA,KDS, LA,KDS,
PX}KKDS
The KDS then communicates all this information back to A, including
also the nonce NA,AS which associates this response
with the request that triggered it.
This AS Response message is protected with the long-term key
KA of the principal A claimed in the request
(the KDS learns this key by retrieving it from the RS).
-
A -> TGS: B, LA,B,
NA,TGS,
[{EPAC}Kx[^]'|xu'A,KDS,]
TktA,KDS, {A, CA,TGS,
[K^A,KDS,]
TA,TGS} KA,KDS
2 (TGS Request: Ask for ticket to server.)
When A receives the AS Response message from the KDS, A can
correctly interpret it (that is, decrypt it, and thereby learn the session key
KA,KDS) only if it "really is A" (in the sense of
knowing the named client's long-term key KA). For the
same reason, A is convinced that the AS Response message really did
come from the genuine KDS server (that is, no "reverse authenticator" is
necessary here-the message itself is "self-mutually-authenticating").
A's next step is to send a TGS Request message to the KDS,
containing the principal stringname (not UUID) of the desired target
(non-KDS) server B, and TktA,KDS, thereby requesting a
ticket to B, denoted TktA,B.
As with AS Requests, a desired lifetime LA,B
and a nonce NA,TGS are included in the TGS Request;
and A can also optionally include some authorisation data,
denoted here "EPAC" (evoking "extended privilege attribute certificate"),
to be more properly introduced in
Privilege (Authorisation) Service (PS)
(this option is rarely used in TGS Requests-see below in this
paragraph for the meaning of the notation
Kx[^]'|xu'A,KDS).
But unlike an AS Request, the TGS Request is protected
(or "authenticated"), by including a (forward)
authenticator in it.
This authenticator contains the identity of A and a
timestamp TA,TGS which indicates the
current time-of-day on A's system (and also on KDS' system,
modulo an allowable clock skew, assuming "loosely
(on the order of a few minutes) synchronised
clocks")-it is primarily these two items that "authenticate
A to KDS", in the sense that they prove to the KDS that "A
really does know the session key KA,KDS, now".
Also included in the authenticator are a checksum
CA,TGS binding the otherwise-unprotected (unencrypted)
data in the message
(B, LA,B, NA,TGS)
to the authenticator, and optionally a conversation key
K^A,KDS generated by A.
If A includes the optional key
K^A,KDS in the TGS Request, that key is used
to protect the authorisation data (in the EPAC, with an EPAC seal),
otherwise the key
KA,KDS is used (that's the meaning of the notation
Kx[^]'|xu'A,KDS above).
The authenticator is encrypted with the key KA,KDS.
-
A <­ TGS: A, {B, KA,B,
LA,B, NA,TGS}
Kx[^]'|xu'A,KDS,
TktA,B
2½ (TGS Response: Receive ticket to server.)
The KDS now generates a session key, KA,B,
which is the actual "physical manifestation" of the logical notion of
"authentication" between A and B; it will be used to protect
the initial communications between A and B, and optionally
to support negotiation of subsequent conversation
("true session") key(s) (K^A,B
and/or Kx^^'|xu'A,B) between them.
Then the KDS constructs the ticket TktA,B, naming
A and containing KA,B, as well as the lifetime
LA,B, the authorisation data PAC if it had been
included in the TGS Request, and the transit path PX.
TktA,B is protected with the long-term
key KB of B (that is, the KDS targets this
ticket to B):
-
-
TktA,B =
TktA,X,B =
B, {A, KA,B,
LA,B, [EPAC,] PX} KB
The KDS communicates all this information to A in the
TGS Response message. As with the AS Response message, the TGS Response
message requires no "reverse authenticator".
The KDS uses the key
Kx[^]'|xu'A,KDS
to protect the TGS Response message.
-
A -> B:
TktA,B,
{A, [CA,B,]
[K^A,B,]
TA,B}
KA,B
-
A <­ B:
{[Kx^^'|xu'A,B,]
TA,B}
KA,B
-
A -> B:
{Service Request(s) / Application-level Data}
KxA,B'|xu'
[^[^]]
-
A <­ B:
{Service Response(s) / Application-level Data}
KxA,B'|xu'
[^[^]]
3 (Service Request/Response: Get service from server.)
Finally, A sends a message to B, containing the ticket
TktA,B and an authenticator
(including in it an optional conversation key
K^A,B if it so desires),
protecting the authenticator with KA,B.
B can correctly interpret (decrypt)
TktA,B, thereby learning the named client A and
the session key KA,B (and the other information in
TktA,B), only if it "really is B"
(in the sense of knowing the targeted server's long-term key
KB).
Using the session key KA,B, B then decrypts the
authenticator, which completes the authentication of A to B.
The (mutual) authentication of B to A is finally completed when
B returns to A the reverse authenticator, containing the
same timestamp that A had sent to B,
TA,B, together with an optional conversation key
Kx^^'|xu'A,B if B so desires.
From this point on, A and B can now engage in protected
communications (that is, service request/responses) using either the
session key KA,B or one of the "negotiated"
conversation keys
K^A,B or Kx^^'|xu'A,B
(exactly which of these keys is used is an application-dependent
determination)-that's the meaning of the notation
KxA,B'|xu'
[^[^]].
(The conversation key could be further negotiated at application-level;
for example "exclusive-OR of K^A,B
and Kx^^'|xu'A,B",
but that is beyond the scope of this specification.)
There is no need for A and B to make further exchanges
of tickets, authenticators, and so on, until the conversation key
KxA,B'|xu'
[^[^]]
times out (as indicated by the lifetime LA,B).
(As an optimisation, an initial service request could have
been piggy-backed with the TktA,B and authenticator
message, and its corresponding service response piggy-backed with the
reverse authenticator message-but such piggy-backing is
application-dependent, not an integral feature of the security
architecture.)
Note that the programming model supported by DCE hides
these complications behind API and RPC interfaces, and does not expose
them to application developers. Applications invoke the KDS only indirectly
through the RPC facility (not through a direct API), by "annotating the
binding handle with rpc_c_authn_dce_secret"-see
Protected RPC
and
Integration with RPC Services
,
and the referenced Open Group DCE 1.1 RPC Specification.
The KDS has the principal name krbtgt/cell-name (within
its cell), and it supports the krb5rpc RPC interface, which
supports the following operation:
-
kds_request()
-send a message (via RPC, as always) to the KDS, requesting a ticket
(or privilege-ticket-see
Privilege (Authorisation) Service (PS)
).
The supported messages are those exhibited in the basic Kerberos
protocol just described, namely:
-
AS messages (together comprising the AS Exchange):
-
AS Request-
unauthenticated request to the AS, requesting an initial ticket
(usually a ticket-granting-ticket, but occasionally a
service-ticket).
-
AS Response-
Response to AS Request, returning the requested initial ticket.
-
TGS messages (together comprising the TGS Exchange):
-
TGS Request-
Authenticated request to the TGS, requesting a subsequent
(that is, non-initial) ticket (usually a service-ticket, but
occasionally a ticket-granting-ticket).
-
TGS Response-
Response to TGS Request, returning the requested subsequent ticket.
-
KDS Error-
KDS error message, generated in response to either a failed AS Request
or a failed TGS Request.
- Note:
- In the current version of DCE, only an indirect RPC interface to
the KDS is supported, but no true direct "APIs" (just the
rpc_c_authn_dce_secret RPC "annotation" constant). Such APIs
may be added in a future version.
Privilege (Authorisation) Service (PS)
The DCE Privilege (or Authorisation) Service (PS)
(or Privilege-ticket-granting Service (PTGS)) manages the
privilege attributes associated to principals, and issues credentials
witnessing these privileges. The credentials issued by the PS
are called Privilege Attribute Certificates (PACs) prior to DCE 1.1.
As of DCE 1.1, the PAC has been extended to include additional attributes
stored in the RS, and is called an EPAC.
PACs are carried in (and protected by) privilege-tickets.
EPACS are not carried in privilege-tickets. Instead, a cryptographic
checksum of the EPAC is generated by the Privilege Server when a
privilege-ticket is created. This checksum is called the seal
of the EPAC, and this seal is what is carried in the
privilege-ticket for DCE 1.1 and newer versions. (PACs may still
be carried in the privilege-ticket for legacy reasons.)
In either case, privilege-tickets represent the "authorisation identity"
of clients,
represented by UUIDs (as opposed to their "authentication identity",
represented as a stringname, in non-privilege-tickets). So in this sense
(that is, the sense of identifying the client by UUIDs instead of by
stringname, except optionally), privilege-tickets are sometimes said, by
abuse of language, to be "anonymous".
Privilege-tickets are instances of tickets, and as such participate all
the same general concepts; in particular, a privilege-ticket that is
targeted to a KDS server is called a
privilege-ticket-granting-tickets (PTGT).
But there are three significant features about privilege-tickets that
distinguish them from non-privilege-tickets:
-
The most obvious difference is that privilege-tickets contain a PAC
(prior to DCE 1.1) or an EPAC seal (for DCE 1.1 and newer versions),
but non-privilege-tickets do not.
-
The most counter-intuitive difference is that, although
privilege-tickets contain a "named client" field (a stringname, not a
UUID) and either a PAC containing "client privileges" (UUIDs, not
stringnames) or an EPAC seal containing "extended client privileges",
a different "client" is referred to in each use of this
word: in a privilege-ticket, the "named client"
is the PS in the server's cell, while the "nominated client" to which the
PAC (or EPAC) refers (via its privilege attribute UUIDs) is the actual
initiating client (or a delegate acting on its behalf)
which is requesting access to a targeted server's protected
resources.
It is by this means (that is, by checking that the privilege-ticket
names the PS) that the targeted server can trust that the PS actually
vouches (that is, is responsible) for the PAC (or EPAC).
The terminology nominated client is therefore introduced to denote the
client to which the PAC (or EPAC) refers (via its privilege attribute UUIDs),
and the PAC (or EPAC) is said to nominate A.
(The nominated client is able to use the privilege-ticket because of protocol
guarantees that it knows the session key carried in the privilege-ticket, so
it can, in this sense, "legitimately impersonate" the named client, the PS
in the server's cell.)
-
The final difference between non-privilege-tickets and privilege-tickets
is that non-privilege-tickets carry a transit path field (that
is, a record of the trust chain involved in an authentication) whose trust
the target server is responsible for evaluating, but privilege-tickets
do not carry such a transit path (or rather, they do not carry a
"meaningful" transit path: the transit path is present, but it
always indicates the trivial path consisting only of the target
server's cell).
The responsibility for evaluating the trust path falls, not to the
target server itself, but to the PS in the target server's cell
(which "consumes" the transit path in doing so).
That is to say, in this sense, privilege-tickets are trusted by
the targeted server by virtue of the trust the target server has in
the PS in its cell (in particular, the PS vouches for the identity
of the nominated client and its cell, which is still projected to
the target server in the privilege-ticket's PAC (or EPAC seal)).
PACs contain privilege attributes (that is, client-side access control
information-that portion of the client's credentials to be used in
server-based access control decisions), consisting of:
-
Authentication Flag
Boolean flag, communicated to target servers, indicating whether or
not this PAC has been authenticated by the TCB (and therefore whether or
not the server can trust the PAC, depending on security policy).
Clients have the ability to send unauthenticated (said to be
"merely asserted") PACs to servers, but these must be viewed
suspiciously by the servers. Typically, server security policy will
require that unauthenticated requests are rejected outright, although a
special "UNAUTHENTICATED ACL Entry" is supported to deal with
unauthenticated requests if server security policy allows this-see
ACL Entries and their Types
.
-
(Local) Cell UUID
UUID of the cell to which the client "belongs", and hence the cell
whose PS has initially vouched for the contents of this PAC.
(In a cross-cell operation, PSs in multiple cells vouch for
the PAC's contents.)
The Cell UUID uniquely determines this cell, to which the PAC
is said to refer.
-
Principal UUID
UUID of the principal for which this PAC contains privilege attributes.
The ordered pair <(Local) Cell UUID, Principal UUID> uniquely determines
this principal, to which the Principal UUID and the PAC are said
to refer.
-
Primary Group UUID
UUID identifying the "primary" or "main" group of which the
principal is a member.
The ordered pair <(Local) Cell UUID, Primary Group UUID>
uniquely determines this group, to which the Primary Group UUID
and the PAC are said to refer.
-
Local Secondary Group UUIDs
List (unordered set of distinct elements, possibly empty) of
UUIDs of the "local" "secondary" groups of which the principal is a
member. Each ordered pair <(Local) Cell UUID, Local Secondary Group UUID>,
uniquely determines such a group, to which the Local Secondary Group UUID
is said to refer, and to all of which the PAC is said to refer.
-
Foreign Secondary Group IDs
List of ordered pairs of two UUIDs, <Foreign Cell UUID, Foreign
Secondary Group UUID>, of the "foreign" "secondary" groups of which
the principal is a member. ("Foreign" in the sense of PACs has the
commonsense meaning that the Foreign Cell UUID is not equal to the
(Local) Cell UUID. However, it is not forbidden for a PAC to contain a
Foreign Secondary Group ID whose Foreign Cell UUID component is
equal to the (Local) Cell UUID-it is just inefficient to do so.) Each
such ordered pair uniquely determines such a group, to which the
Foreign Secondary Group ID is said to refer, and to all of which
the PAC is said to refer.
In addition to the identity and group membershop information present
in a DCE 1.0 format PAC, the extended PAC (EPAC) contains optional
delegation controls, optional and required restrictions (both of
which are discussed under the topic, "Delegation", in this chapter),
and extended attributes. EPACS also require the following:
-
Global Group Name
Name consisting of the
UUID identifying the cell to which the client, acting as a
delegate, belongs, and hence the cell whose PS has initially
vouched for the contents of this EPAC. Also the UUID identifying
the "primary" or "main" group of which the principal is a member.
-
Global Principal Name
Name consisting of the
UUID identifying the cell to which the client, acting as a
delegate, belongs. Also the UUID identifying the principal.
For more information on Global Group Names and
Global Principal Names refer to
ID Map Facility RPC Interface
and
ID Map API
.
(The distinction between primary groups and secondary groups is
made for administrative purposes only, and is largely historical.
In particular, the two kinds of groups are not discriminated between in
the Common Access Determination Algorithm (see
The Common Access Determination Algorithm for Delegation
).)
- Note:
-
As is seen from the structure of PACs and EPACs above (see also
Privilege Attribute Certificates (PACs)
,
as well as the Common Access Determination Algorithm in
Common Access Determination Algorithm
),
authorisation identities in DCE are represented not by a
single UUID, but by a pair of UUIDs: <Cell UUID,
Subject UUID> (where, for the purposes of this discussion, "subject"
means principal or group).
At first glance this may seem odd: since UUIDs are "unique in space
and time", one wonders why two UUIDs are needed to identify one security
subject. The answer has to do not with identification per se,
but in the trust to be invested in the uniqueness of UUIDs
(especially in an environment where untrusted other parties may be
generating some of the UUIDs), and especially in the
containment of damage in the event of UUID non-uniqueness. For,
assuming a single-UUID scheme, consider the situation where
a cell X were compromised, but that no other cell were aware of
this compromise. In that situation, the compromiser of cell X
could then assign arbitrary (bogus) UUIDs to principals and groups
in X-these could even be the (otherwise genuine) UUIDs assigned to
principals and groups in (any) other cells. The (bogus) clients from cell
X would then be able to authenticate to servers in X and in
those other cells that "trust X" (through (potentially chains of)
cross-registrations), and would then be able to
access all protected objects in those servers (because the server
would be unable to distinguish the bogus UUIDs from the genuine ones).
That is to say, under a single-UUID scheme, the compromise of a single
cell would compromise the security of all protected objects in all
cells that "trust X". This is unacceptable. In the
double-UUID scheme, this doesn't happen: the compromise of cell X
compromises the security, not of all protected objects in cells
that "trust X", but only of those protected objects (in cells that
"trust X") that themselves "trust X", in the sense of only
those protected objects whose very ACLs grant access to subjects from X.
This is a more acceptable containment of damage.
The manner in which privilege-tickets figure into the DCE security
environment is that the basic (intra-cell) Kerberos authentication
protocol is extended to include the PS, as outlined below.
Consider a client A that desires to obtain service from
a server B (see
KDS+PS Protocol
).
Figure: KDS+PS Protocol
-
A -> AS: A, KDS, LA,KDS,
NA,AS
-
A <­ AS: A, {KDS,
KA,KDS,
LA,KDS,
NA,AS}
KA,
TktA,KDS
1 (AS Request/Response: Get ticket to KDS.)
First, A obtains a ticket, TktA,KDS, from the AS
(naming A, targeted to the KDS, and containing a session key
KA,KDS), exactly as in the basic authentication
protocol (above).
-
A -> TGS: PS, LA,PS,
NA,TGS, TktA,KDS,
{A, CA,TGS,
[K^A,KDS,]
TA,TGS} KA,KDS
-
A <­ TGS: A, {PS, KA,PS,
LA,PS, NA,TGS}
Kx[^]'|xu'A,KDS,
TktA,PS
2 (TGS Request/Response: Get ticket to PS.)
Next, A sends its TktA,KDS and the principal
stringname of the PS to the KDS, requesting a ticket,
TktA,PS, to the PS.
Still following the basic authentication protocol, the KDS obliges
by returning the requested TktA,PS (naming A,
targeted to the PS, and containing a session key KA,PS)
to A.
-
A -> PS: KDS, L~A,KDS,
NA,PS, TktA,PS,
{A, CA,PS,
[K^A,PS,]
TA,PS} KA,PS
3 (PS Request: Ask for privilege-ticket to KDS.)
Now, A sends TktA,PS to the PS, thereby
requesting a privilege-(ticket-granting-)ticket (PTGT), denoted
PTktA,KDS, targeted to the KDS.
The PS decrypts TktA,PS,
learning A's stringname and the session key KA,PS.
(The "~"-notation just distinguishes a new occurrence of a data item
-in this case, the lifetime of a key to be shared between A and the
KDS-from a similar one that has occurred previously in this run of the
protocol.)
-
A <­ PS: A, {PS,
K~A,KDS, L~A,KDS,
NA,PS}
Kx[^]'|xu'A,PS,
PTktA,KDS
3½ (PS Response: Receive privilege-ticket to KDS.)
The PS constructs PACA from A's privilege
information (which it retrieves from the RS), and then constructs
the privilege-ticket, PTktA,KDS.
This PTktA,KDS names the
PS itself (not A), contains PACA
(that is, nominates A), contains a new session
key K~A,KDS (generated by the KDS),
and is protected with the long-term key, KKDS, of the KDS:
-
-
PTktA,KDS = KDS, {PS,
K~A,KDS, L~A,KDS,
PACA, PX} KKDS
(The mechanics of how this PTktA,KDS gets generated
-in particular, how its encrypted part gets encrypted in the key
KKDS-is implementation-dependent, and not
specified in this document.
One method is that the encryption key KKDS can be shared
between the KDS and PS (the manner is unspecified here, but it must be
done in some secure manner-for example, the PS and KDS could be
co-located on the same host, or even in the same process).
Another method (usable in implementations where the KDS and PS are
not co-located) is that the PS sends a TGS Request
including PACA to the KDS
(PS -> TGS: KDS, LPS,KDS, NPS,TGS,
{PACA}Kx[^]'|xu'PS,KDS,
TktPS,KDS, {PS, CPS,TGS, [K^PS,KDS,]
TPS,TGS} KPS,KDS),
receiving in the corresponding TGS Response the ticket
Tkt~PS,KDS = KDS, {PS, KPS,KDS,
LPS,KDS, PACA,
PX}KKDS
-this ticket then serves as the required PTktA,KDS.)
In particular, note that the PACA in
PTktA,KDS contains UUIDs describing A's privilege
attributes for authorisation purposes, but does not necessarily contain the
principal stringname of A (though it may do so optionally) for
authentication purposes.
The PS returns K~A,KDS and PTktA,KDS
to A (protecting this message with
Kx[^]'|xu'A,PS).
As with AS and TGS Responses, the PS Response requires no "reverse
authenticator".
-
A -> TGS: B, LA,B,
N~A,TGS, PTktA,KDS,
{PS, C~A,TGS,
[Kx~^'|xu'A,KDS,]
T~A,TGS} K~A,KDS
4 (TGS Request: Ask for privilege-ticket to server.)
At this point, A proceeds along the same lines as the basic
authentication protocol, but now using the privilege-ticket
PTktA,KDS
instead of the non-privilege-ticket TktA,KDS (it is
A's knowledge of K~A,KDS that enables it to use
PTktA,KDS, by "legitimately posing" as PS).
Thus, A sends a message to the KDS, containing the principal
stringname of B and the PTktA,KDS,
requesting a privilege-ticket,
PTktA,B targeted to B.
(Note incidentally that the identity in the authenticator is that of the
PS, not A, because the named client in the privilege-ticket
PTktA,KDS is PS, not A.)
This message is protected with the session key K~A,KDS.
-
A <­ TGS: PS, {B, KA,B,
LA,B, N~A,TGS}
Kx~[^]'|xu'A,KDS,
PTktA,B
4½ (TGS Response: Receive privilege-ticket to server.)
The KDS treats this request just as it would an ordinary request (that
is, one using a non-privilege-ticket instead of a privilege-ticket), with
the additional function of "blindly copying" (that is, without
interpreting) the PACA received in
PTktA,KDS into the privilege-ticket,
PTktA,B.
That is, the KDS constructs a PTktA,B,
with PS as its named client, containing a session key
KA,B and PACA,
and protected with the long-term key, KB, of B:
-
-
PTktA,B = B, {PS,
KA,B, LA,B,
PACA, PX} KB
The KDS returns KA,B and
PTktA,B to A, in a message protected by
Kx~[^]'|xu'A,KDS.
-
A -> B: PTktA,B,
{PS, [CA,B,]
[K^A,B,]
TA,B} KA,B
-
A <­ B:
{[Kx^^'|xu'A,B,]
TA,B} KA,B
-
A -> B:
{Service Request(s) / Application-level Data}
KxA,B'|xu'
[^[^]]
-
A <­ B:
{Service Response(s) / Application-level Data}
KxA,B'|xu'
[^[^]]
5 (Service Request/Response: Get service from server.)
Finally, A sends its privilege-ticket,
PTktA,B, to B
(protecting this message with KA,B).
B decrypts PTktA,B, learning its
named client (which must be PS, so B knows it can trust
PACA), PACA nominating A
(though not the principal stringname of A, except optionally),
and the session key KA,B.
A and B can now proceed with their interactions exactly
as in the basic authentication protocol, with the additional
functionality that B can make its authorisation decisions
based on the trusted PACA
information contained in PTktA,B.
As with the KDS, no APIs to the PS are directly supported in DCE.
Instead, the use of the PS is signaled in RPC applications by
the use of the rpc_c_authz_dce identifier (see
Protected RPC
and
Integration with RPC Services
,
and the referenced Open Group DCE 1.1 RPC Specification).
The PS has the principal name dce-ptgt (within its cell),
and it supports the rpriv RPC interface, which supports the
following operations:
-
ps_request_ptgt()
-request a privilege-ticket-granting-ticket (as in the protocol just
described).
-
ps_request_eptgt()
-request an extended privilege certificate to the ticket-granting service (PS).
-
ps_request_become_delegate()
-request a privilege-ticket-granting-ticket for an intermediary caller (server)
so the intermediary can become a delegate for the caller.
-
ps_request_become_impersonator()
-request a privilege-ticket-granting-ticket for an intermediary caller (server)
so the intermediary can become an impersonator for the caller.
Name-based versus PAC-based Authorisation
- Note:
- Prior to DCE 1.1,
name-based authorisation was included in DCE primarily
for support of legacy applications only; its use for
any other purpose was discouraged.
However, in DCE 1.1 and newer versions, since delegation
is being supported, name-based
authorisation is being used to ensure the integrity of
the arguments across the network due to the introduction
of delegated identities.
In addition to the PAC-based authorisation service described
above, DCE also supports another authorisation service, said to
be (string)name-based. It is signaled in RPC applications by
the use of the identifier rpc_c_authz_name. Name-based
authorisation is a very primitive service compared to the sophisticated
privilege service described above, in several senses (some terminology
is used here that won't be introduced until later sections):
-
It is based solely on KDS-related protocols, not PS-related ones
(see also the cross-cell protocol in
Cells-Cross-cell Authentication and Authorisation
);
that is, the PS is not visited in the course of a name-based
authorisation.
In technological terms: no privilege-tickets are involved, only
non-privilege-tickets; thus the ticket's "nominated client" is not that
referred to by a PAC (because there is no PAC), but is instead the "named
client", identified by principal stringname.
-
It is not flexible or extensible, because the only "privilege
attribute" (or "authorisation information") projected from the client
to the server is the client's principal stringname, not a UUID profile
(as in a PAC). In particular, there is no support for "name-based groups".
-
There is no DCE support for "name-based ACLs", nor
for "name-based permissions" or "name-based access
control managers", "name-based access control editors" or
"name-based common access determination algorithm".
-
It doesn't afford good cross-cell security, because the PS isn't visited.
The point here is that while the KDS specifications have it blindly copying
authorisation information and evaluating trust chains at the level of
immediate cross-cell links, the PS specifications have it "vetting"
(or "modulating", or "tempering") authorisation information and
evaluating the global shape of trust chains. This is discussed in
Cells-Cross-cell Authentication and Authorisation
.
Cells-Cross-cell Authentication and Authorisation
A cell (sometimes called realm or domain, when the
focus is solely on security) is the basic unit of configuration
and administration in a DCE environment.
Each cell contains one RS/KDS/PS triple (potentially replicated).
In the preceding sections, only the per-cell nature
of the DCE security features has been discussed. In this section,
the manner in which these features are extended across cells is
explained. This creates the effect of a multi-cell
DCE TCB (though different levels of trust may be invested in
different cells). As will be seen, principals in distinct cells can
establish trust chains to one another. But such trust chains are
inherently less trustworthy than trust relationships within a single
cell. This is due simply to general security principles (and is not
specific to DCE security), namely cross-cell trust chains are longer
than intra-cell ones, and trust chains are in general (by the
"fail-safe" principle) no more trustworthy than their weakest link
(and the longer the chain the higher the likelihood of some link being
compromised). This simply reinforces the general security principle
that entities "near" to "self" are more trustworthy (easier to
protect) than entities "farther away".
Consider, therefore, a client A in cell X, and a server
B in cell Y.
Denote each cell's security services with subscripts (for example,
KDSX, KDSX,Y-but when
they appear in subscripts themselves they will be upgraded to avoid
embedded subscripts; for example, KKDSX,
KKDSXY).
The problem is to extend the single-cell security model to this
multi-cell case.
In terms of trust chains, A trusts TCBX,
and B trusts TCBY, so what remains is to
establish a trust link between TCBX and
TCBY. In terms of keys, in order for
A and B to communicate securely, they need to share a session
key they both trust, and it is this key distribution problem that is at
the crux of the cross-cell security model. In terms of tickets,
A must present to B a privilege-ticket protected with
B's long-term key, but the normal distributor of tickets to
A, KDSX, does not know B's long-term
key (nor should it-only KDSY should
know B's key).
The solution involves cross-registering the cell principals
KDSX and KDSY in one another's cells,
using (two copies of) a "surrogate" cell principal, as follows (see
Cross-Registration Mediating Cross-Cell Trust Link
).
In order for clients in cell X to be able to (mutually)
authenticate to servers in cell Y, KDSY
is endowed with an additional surrogate principal identity,
denoted KDSX,Y, and
registered in RSY with a new long-term key
KKDSXY (distinct from the long-term key,
KKDSY, of KDSY itself-
which is also denoted KDSY,Y in this context);
and in addition, this same surrogate principal
KDSX,Y is also registered with the
same key KKDSXY in RSX,
as another copy of the surrogate of the KDSX,Y
in RSY.
That is, it is the cross-cell surrogate (double) principal
KDSX,Y which mediates the
KDSX -> KDSY trust link
(as detailed below, the point is that KDSY knows
the long-term key of the principal KDSX,Y
in the foreign cell X).
As a communicating entity (that is, as an RPC server),
KDSX,Y is typically implemented to be
the same as KDSY (in cell Y)
or as KDSX (in cell X), respectively.
- Note:
- The use of arrow notation to denote a trust link,
"KDSX -> KDSY",
is distinct from, and not to be confused with, the use of arrow
notation to denote communications messages.)
Figure: Cross-Registration Mediating Cross-Cell Trust Link
The above discussion concerned only the "unilateral" mediation of
trust; that is, from clients in X to servers in Y.
Conversely, for clients in Y to be able to authenticate to
servers in X, KDSX is endowed with
a similar cross-cell surrogate double principal identity, denoted
KDSY,X, registered in both RSX
and in RSY, with a new long-term key
KKDSYX.
That is, KDSY,X mediates the
KDSY -> KDSX trust link.
In general (that is, for a given pair of cells X and Y),
zero, one or two of the principals KDSX,Y and
KDSY,X may exist.
And in the case where both exist, they may be equal
(KDSX,Y = KDSY,X; that is,
KKDSXY = KKDSYX)
or they may be distinct
(KDSX,Y != KDSY,X; that is,
KKDSXY != KKDSYX).
These are called the symmetric (or one-key) and
asymmetric (or two-key) cases of mutual trust
peers, respectively.
Cross-registration is an explicit expression of trust;
cells that do not trust one another do not cross-register with
one another.
The naming model for the principal stringnames of the cross-cell
surrogates involved in cross-registration is specified as follows.
Suppose the cell name of X is
(in full DCE syntax) /.../cellX
and the cell name of Y is /.../cellY, so that the per-cell
principal name of KDSX (= KDSX,X)
is krbtgt/cellX (within RSX) and
the per-cell principal name of KDSY
(= KDSY,Y) is krbtgt/cellY
(within RSY) (that is, in full DCE syntax,
/.../cellX/krbtgt/cellX and /.../cellY/krbtgt/cellY,
respectively).
Then within RSX, both
KDSX,Y and
KDSY,X are identified by the single per-cell
principal name krbtgt/cellY (that is, in full DCE syntax,
/.../cellX/krbtgt/cellY).
And within RSY both KDSX,Y and
KDSY,X are named
krbtgt/cellX (that is, /.../cellY/krbtgt/cellX).
- Note:
-
(The following comments are worded in terms of RSX, though
the same comments apply to RSY, of course.)
According to the above naming model, the (potentially distinct)
cross-cell principals KDSX,Y and
KDSY,X in RSX have the
same stringname, namely /.../cellX/krbtgt/cellY.
Thus, those principals (and the keys associated to them)
cannot be distinguished within RSX by their stringnames.
In the symmetric case this causes no confusion, because there
is only one long-term key associated to the name
/.../cellX/krbtgt/cellY.
In the asymmetric case (if it is supported by a given implementation),
some administrative means of distinguishing between the (distinct)
"outgoing" key
(KKDSXY) and "incoming" key
(KKDSYX) must be provided by RSX.
In practice, the policy of most cells is to support only the
symmetric case (and indeed, most implementations of DCE
do not provide the required administrative means to support the
asymmetric case).
That is, while the protocols as specified in this specification
support both symmetric and asymmetric mutual trust
peers, most cells (and implementations) support only the
symmetric case.
This has implications for interoperability between any pair
of cells supporting different policies (namely, if one of the
cells requires that its trust relationship with the other
cell be symmetric, while that other cell requires that the
relationship be asymmetric, then the two cells cannot be mutual
trust peers-full, unrestricted bidirectional authentication
between clients and servers in the two cells cannot exist).
The consequence of cross-registration is to enable the establishment of
trust relationships between clients and servers in different cells, as
the following steps outline. The discussion in this outline is briefer
than the previous ones, since so much of it has already been explained
in the previous outlines (see
Cross-Cell Protocol (Single-hop)
).
Figure: Cross-Cell Protocol (Single-hop)
-
A -> ASX: A,
KDSX, LA,KDSX,
NA,ASX
-
A <­ ASX: A,
{KDSX, KA,KDSX,
LA,KDSX, NA,ASX}
KA, TktA,KDSX
-
A -> TGSX: PSX,
LA,PSX, NA,TGSX,
TktA,KDSX, {A,
CA,TGSX, [K^A,KDSX,]
TA,TGSX} KA,KDSX
-
A <­ TGSX: A,
{PSX, KA,PSX,
LA,PSX, NA,TGSX}
Kx[^]'|xu'A,KDSX,
TktA,PSX
-
A -> PSX: KDSX,
L~A,PSX, NA,PSX,
TktA,PSX, {A,
CA,PSX, [K^A,PSX,]
TA,PSX} KA,PSX
-
A <­ PSX: A,
{PSX, K~A,KDSX,
L~A,KDSX, NA,PSX}
Kx[^]'|xu'A,PSX,
PTktA,KDSX
1; 2; 3 (Get ticket to local KDS; Get ticket to local PS; Get
privilege-ticket to local KDS.)
Client A in cell X desires a service from server
B in a foreign cell Y. A begins, as usual, by
acquiring its ticket to KDSX,
TktA,KDSX, from ASX,
and its privilege-ticket, PTktA,KDSX,
from PSX, for services within cell X.
-
A -> TGSX: B,
LA,B, N~A,TGSX,
PTktA,KDSX, {PSX,
C~A,TGSX,
[Kx~^'|xu'A,KDSX,]
T~A,TGSX} K~A,KDSX
-
A <­ TGSX: PSX,
{KDSX,Y, KA,KDSXY,
LA,KDSXY, N~A,TGSX}
Kx~[^]'|xu'A,KDSX,
TktA,X,KDSXY
4 (Get ticket to foreign KDS.)
Following the usual protocol, A now requests
KDSX for a privilege-ticket to B.
But instead of that, KDSX returns
to A a cross-cell referral (ticket-granting-)ticket,
TktA,X,KDSXY,
which names PSX, nominates A,
and is targeted to the surrogate principal
KDSX,Y in cell X:
-
-
TktA,X,KDSXY =
KDSX,Y, {PSX,
KA,KDSXY,
LA,KDSXY,
PACA,X, PX,Y}
KKDSXY
As for any request for any ticket or privilege-ticket,
KDSX blindly copies PACA,X
from PTktA,KDSX into
TktA,X,KDSXY,
and returns it to A with a session key
KA,KDSXY between A and
KDSX,Y. Note that
TktA,X,KDSXY
is not yet considered to be a "privilege-ticket" at this point,
because it names PSX instead of PSY.
This indicates that PSY has
not yet had an opportunity to "vet" ("modulate", "temper")
PACA,X and the transit path
PX,Y (indicating the trust link
TCBX -> TCBY).
-
A -> TGSY:
PSY, LA,PSY,
NA,TGSY,
TktA,X,KDSXY,
{PSX, CA,TGSY,
[K^A,KDSXY,]
TA,TGSY}
KA,KDSXY
-
A <­ TGSY:
PSX, {PSY,
KA,PSY, LA,PSY,
NA,TGSY}
Kx[^]'|xu'A,KDSXY,
TktA,X,Y,PSY
5 (Get ticket to foreign PS.)
Now, A presents this TktA,X,KDSXY
to (not the surrogate KDSX,Y in cell X, but to)
the surrogate KDSX,Y in cell Y (which
recognises TktA,X,KDSXY
as a well-formed ticket because it is protected with its
long-term key, KKDSXY), requesting a
ticket, TktA,X,Y,PSY,
naming PSX, nominating A,
and targeted to PSY:
-
-
TktA,X,Y,PSY =
PSY, {PSX,
KA,PSY, LA,PSY,
PACA,X, PX,Y}
KPSY
KDSY (KDSX,Y) issues this
TktA,X,Y,PSY (blindly copying
PACA,X from
TktA,X,KDSXY to
TktA,X,Y,PSY in the usual manner)
and returns it and its session key KA,PSY
to A.
Again, TktA,X,Y,PSY is not yet
considered to be a "privilege-ticket".
-
A -> PSY: KDSY,
L~A,KDSY, NA,PSY,
TktA,X,Y,PSY,
{PSX, CA,PSY,
[K^A,PSY,] TA,PSY}
KA,PSY
-
A <­ PSY: PSX,
{PSY, K~A,KDSY,
L~A,KDSY, NA,PSY}
Kx[^]'|xu'A,PSY,
PTktA,KDSY
6 (Get privilege-ticket to foreign KDS.)
Next, A presents this
TktA,X,Y,PSY
to PSY, requesting a privilege-ticket,
PTktA,KDSY (naming PSY,
nominating A, and targeted to KDSY),
in the usual manner:
-
-
PTktA,KDSY = KDSY,
{PSY, K~A,KDSY,
L~A,KDSY, PACA,Y,
PY} KKDSY
PSY honours this request, but since
RSY does not hold A's privilege attributes,
PSY instead retrieves PACA,X
from TktA,X,Y,PSY,
and inspects it, in the process vetting (modulating,
tempering) it for use in Y, thereby turning it into
a "PACA,Y".
(This vetting could potentially, depending on policy, involve such
activities as discarding some privilege attributes disallowed
in cell Y, or translating "X-privileges" into
"Y-privileges", and so on.)
This PACA,Y is placed into
PTktA,KDSY, becoming the authorisation
information nominating A to servers in cell Y.
Moreover, PSY "consumes" the transit path
PX,Y (that is, vets it, and replaces it with the
trivial transit path PY).
PSY also returns to A a new session key
K~A,KDSY between
A and KDSY, as usual.
-
A -> TGSY: B,
LA,B, N~A,TGSY,
PTktA,KDSY, {PSY,
C~A,TGSY,
[Kx~^'|xu'A,KDSY,]
T~A,TGSY} K~A,KDSY
-
A <­ TGSY: PSY,
{B, KA,B, LA,B,
N~A,TGSY}
Kx~[^]'|xu'A,KDSY,
PTktA,B
-
A -> B: PTktA,B,
{PSY, [CA,B,]
[K^A,B,] TA,B}
KA,B
-
A <­ B: {[Kx^^'|xu'A,B,]
TA,B} KA,B
-
A -> B:
{Service Request(s) / Application-level Data}
KxA,B'|xu'
[^[^]]
-
A <­ B:
{Service Request(s) / Application-level Data}
KxA,B'|xu'
[^[^]]
7; 8 (Get privilege-ticket to server; Get service from server.)
Armed with a PTktA,KDSY (containing
PACA,Y) usable in Y, A can now proceed
according to the usual Kerberos protocol to request services from
servers (such as B) in cell Y: send the stringname of B
and PTktA,KDSY to KDSY
requesting a privilege-ticket, PTktA,B,
to B, and so on.
Since this is exactly the same as the single-cell authentication protocol
(which has already been explained), it is not repeated here.
Note in particular that the privilege-ticket that
KDSY receives from the foreign
principal A, PTktA,KDSY, looks exactly
the same as the privilege-tickets that KDSY
receives from the local principals within its own cell
(KDSY cannot distinguish between the two
kinds of privilege-tickets).
The same is true of the privilege-ticket that B receives from A:
-
-
PTktA,B = B, {PSY,
KA,B, LA,B,
PACA,Y, PY}
KB
That is to say, B cannot tell from this privilege-ticket's
format that A is a foreign principal (it can only tell so by
looking into A's identity information carried in
PACA,Y).
The Complete Cross-cell Scenario
The preceding outline envisions only the case where a direct
trust link has been established between cells X and Y. The
general case of indirect trust chains (that is, whose number of links
is greater than 1, with intermediate cells intervening between X
and Y) is an inductive generalisation of that one, whereby A
engages in a succession of cross-cell referrals from one cell's KDS
server to another's (intermediate PS servers are not visited), bringing
it "ever closer to" (and eventually arriving at) B's cell, at each
stage engaging in the protocol outlined above. (The various cells' KDS
servers only "indirectly refer" to one another, never "directly
chain" to one another, in the sense that during the performance of
their mainline services they only ever "communicate" cross-cell with
one another via the intermediary of A, never communicating directly
to one another-they only do so for such incidental purposes as parsing
stringnames into their component pieces, or for cross-cell key
management. See
ID Map Facility
and
Key Management Facility
.)
The successive intermediate cross-cell referral tickets contain at each
stage a record (transit path) of the trust chain of cells to that point,
say:
-
-
PX,Z´,
Z´´,···,
Z´´´,
Z´´´´ =
TCBX ->
TCBZ´ ->
TCBZ´´ ->
··· ->
TCBZ´´´ ->
TCBZ´´´´
and so the corresponding cross-cell referral ticket may be denoted:
-
-
TktA,X,Z´,
Z´´,···,Z´´´,
KDSZ´´´Z´´´´ =
KDSZ´´´,
Z´´´´, {PSX,
KA,
KDSZ´´´Z´´´´,
LA,
KDSZ´´´Z´´´´,
PACA,X,
PX,Z´,
Z´´,···,Z´´´,
Z´´´´}
KKDSZ´´´Z´´´´
When the target server's cell, Y, is eventually reached,
the corresponding cross-cell referral ticket,
TktA,X,Z´,
Z´´,···,
Z´´´´,
KDSZ´´´´Y,
is used to obtain a (service) ticket to the PS server in cell Y:
-
-
TktA,X,Z´,
Z´´,···,
Z´´´,Z´´´´,
Y,PSY = PSY,
{PSX, KA,PSY,
LA,PSY, PACA,X,
PX,Z´,
Z´´,···,
Z´´´,Z´´´´,
Y} KPSY
This
TktA,X,Z´,
Z´´,···,
Z´´´,Z´´´´,
Y,PSY is then presented to PSY,
which vets the PACA,X (turning it into a
"PACA,Y") and the transit path
PX,Z´,
Z´´,···,
Z´´´,
Z´´´´,Y
("consuming" the latter), and returns a privilege-ticket that A
can use in cell Y:
-
-
PTktA,KDSY = KDSY,
{PSY, K~A,KDSY,
L~A,KDSY, PACA,Y,
PY} KKDSY
Finally, this PTktA,KDSY is presented to
KDSY, which uses it to generate a
(service-)privilege-ticket, PTktA,B:
-
-
PTktA,B = B, {PSY,
KA,B, LA,B,
PACA,Y, PY}
KB
In summary, the sequence of communications (RPCs) involved in a
complete protected (authenticated/authorised) RPC from a client A in
cell X to a server B in cell Y, transiting through cells
Z´, Z´´,
···, Z´´´,
Z´´´´ can be depicted as shown in
Cross-Cell Protocol (Multi-hop)
.
Figure: Cross-Cell Protocol (Multi-hop)
Following are very brief descriptions of each step (for details see
above, or the chapters to follow). In each step after the first one,
A presents to its target the ticket (or privilege-ticket) it
received from the previous step.
-
1 (Get ticket to local KDS.)
A presents its identity to KDSX,
requesting ASX for an initial ticket,
TktA,KDSX to KDSX,
and receives it.
-
2 (Get ticket to local PS.)
A presents TktA,KDSX to KDSX,
requesting TGSX for a ticket,
TktA,PSX
(= TktA,X,PSX),
to PSX, and receives it.
-
3 (Get privilege-ticket to local KDS.)
A presents TktA,PSX to PSX,
requesting PSX for a privilege-ticket,
PTktA,KDSX, to KDSX,
and receives it. (Note that steps 1-3 typically happen at A's
"login time", while the remaining steps occur "on demand" when A
desires service from an end-service B.)
-
4 (Get ticket to foreign KDS.)
A presents PTktA,KDSX to KDSX,
requesting TGSX for a privilege-ticket to B,
but instead receives a cross-cell referral ticket,
TktA,X,KDSXZ´, to
KDSX,Z´.
(The cross-cell tickets issued in this sequence of steps are
not yet privilege-tickets, even though they carry authorisation
information (a PAC) for the nominated client, A.
This is explained in
Cells-Cross-cell Authentication and Authorisation
.)
-
5 (Get ticket to foreign KDS.)
A presents
TktA,X,KDSXZ´ to
KDSZ´,
requesting TGSZ´ for a ticket to
PSY, but instead receives a cross-cell referral ticket,
TktA,X,
Z´,
KDSZ´Z´´, to
KDSZ´,Z´´.
-
··· (Get tickets to foreign KDSs.) ···
-
6 (Get ticket to foreign KDS.)
A presents
TktA,X,Z´,
Z´´,···,
Z´´´,
KDSZ´´´Z´´´´
to KDSZ´´´´,
requesting TGSZ´´´´
for a ticket to PSY,
but instead receives a cross-cell referral ticket,
TktA,X,Z´,
Z´´,···,
Z´´´,
Z´´´´,
KDSZ´´´´Y,
to KDSZ´´´´,Y.
-
7 (Get ticket to foreign PS.)
A presents
TktA,X,Z´,
Z´´,···,
Z´´´,
Z´´´´,
KDSZ´´´´Y
to KDSY, requesting TGSY for a ticket,
TktA,X,Z´,
Z´´,···,
Z´´´,
Z´´´´,Y,PSY,
to PSY, and receives it.
(Again, this
TktA,X,Z´,
Z´´,···,
Z´´´,Z´´´´,
Y,PSY, is not yet a privilege-ticket.)
-
8 (Get privilege-ticket to foreign KDS.)
A presents
TktA,X,Z´,
Z´´,···,
Z´´´,
Z´´´´,Y,PSY,
to PSY, requesting PSY
for a privilege-ticket, PTktA,KDSY,
to KDSY, and receives it.
-
9 (Get privilege-ticket to server.)
A presents PTktA,KDSY
to KDSY,
requesting TGSY for a privilege-ticket,
PTktA,B, to B, and receives it.
-
10 (Get service from server.)
A presents PTktA,B to B,
requesting B for service, and receives it (provided that
A's PACA,Y grants it access per
B's access determination algorithm and the ACL protecting
the accessed object).
Of course, the DCE RPC programming model hides all these complexities
from the application programmer.
Multi-Hop Trust Chains
In the descriptions given above, no solution has yet been given to the
following closely related twin problems, which together are referred
to as the multi-hop trust chain problem:
-
How does each cell's KDS server "know" which foreign KDS servers to
refer clients to?
That is, how does each KDSZ,
which nominally knows only about the foreign KDSs it is
directly cross-registered with, understand the overall global
graph of other KDSW's direct
cross-registrations, so that the cross-cell referral ticket,
TktA,X,Z,
KDSZW,
that KDSZ´ returns to a client A
actually does point A "closer to" its targeted end-server B,
guaranteeing that any sequence of cross-cell referrals
KDSX ->
KDSZ´ ->
KDSZ´´ -> ··· ->
KDSZ´´´ ->
KDSZ´´´´ -> ···
ultimately terminates (at KDSY)?
-
How does each cell's PS server "know" whether or not to trust a
transit path?
That is, how does each PSY know whether or not
the transit path
PX,Z´,
Z´´,···,
Z´´´,
Z´´´´,Y,
presented to it for vetting, conforms to a "trusted shape"?
This revision of this specification does not, in fact, specify
a solution to this multi-hop trust chain problem. Thus, the only
solution to the cross-cell trust chain problem that is fully specified
in this revision of DCE is the single-hop (direct) case.
Nevertheless, it is anticipated that a solution to the multi-hop trust
chain problem will be specified in a future revision of DCE,
and that the specified solution will be the so-called
hierarchical (or up-over-down) trust chain solution,
which is depicted in
Hierarchical Trust Chains
.
In that figure, the arrowed lines indicate trust links, while the
non-arrowed lines indicate namespace parent/child relationships (solid
ones indicate direct links; dotted ones indicate a span of
several generations; dashed ones indicate the step from a
cell's TCB to a principal within that cell).
Very briefly, the idea is that the hierarchical structure of cell
names (indicated in
Hierarchical Trust Chains
by sequences of atomic names in angle
brackets) is exploited to navigate an "up-over-down" path from client
to server, seeking the "least common trust peer link" between the
client's cell ancestry and the server's cell ancestry.
Only a direct relationship between these cell ancestries is deemed
acceptable (not a chain through intermediate ancestries,
Z´´, as indicated).
Figure: Hierarchical Trust Chains
Access Control Lists (ACLs)
- Note:
- Much of the ACL Facility specified in DCE is "modelled after"
the ACL Specification in POSIX P1003.6 Draft 12 (with allowable
extensions). However, no claim of "conformance to" POSIX ACLs
is made here, because of the preliminary (draft) nature of
the POSIX ACL model.
Harmonisation of the ACL Facility specified here with the final
POSIX ACL Standard is for future study. (Note, for example,
the disappearance and reappearance of MASK_OBJ in various POSIX drafts.)
The Access Control List (ACL) Facility manages
server-side access control information, thereby enabling a
server to control clients' access to the (protected) objects
(that is, objects to which ACLs are attached) managed by the server.
The ACL Facility comprises ACLs and ACL Managers, which are
discussed in this section and
ACL Managers, Permissions, Access Determination Algorithms
.
An ACL consists of:
-
ACL Manager Type UUID
UUID identifying the semantics of the ACL; that is, the kind
or type of ACL Manager that can interpret the ACL (see below),
especially with respect to the permissions granted or denied in the
ACL Entries (ACLEs). By this means, protected
objects are partitioned into classes, according to the types of ACL
managers that can interpret their ACLs. An object protected by ACLs
can have an arbitrary number of ACLs associated with it, but at most one
of any given ACL Manager Type (see
Multiple ACLs and ACL Managers
).
-
Default Cell UUID
UUID identifying the cell to which the ACLEs of "local"
(non-"foreign") type apply (see below), and said to be the cell to
which the ACL refers.
- Note:
- The ACL's default cell UUID does not necessarily identify the
cell the protected object itself belongs to (that is, the cell
in which the server protecting the object is registered as
a principal), though this will typically be the case.
-
ACL Entries (ACLEs)
Specifies the access rights of subjects to the protected object,
according to the access determination algorithm (see below).
ACL Entries and their Types
An ACLE consists of:
-
ACLE Type
This indicates how the ACLE is to be interpreted by the access
determination algorithm (see below).
-
Tag UUID Field(s)
UUID(s) (0, 1 or 2 of them), of some combination of cells,
principals and groups, used to "qualify" certain ACLE types,
as explained below.
-
Permissions Field
Specifies access rights (up to 32 of them) afforded by this ACLE.
The semantics of these access rights are interpretable only by
ACL Managers of the ACL Manager type specified by the ACL (see below).
The ACLE Types are organised into the following taxonomy:
-
Local ACLE types
Refer to subjects in the ACL's default cell:
-
USER_OBJ or UO (no Tags)
Establishes permissions for the object's owning user (in the
POSIX sense), identified by the ordered pair <Default Cell UUID,
Owning Principal UUID>, to which the USER_OBJ ACLE
is said to refer.
The Owning Principal UUID is a UUID determined in an
application-specific way (not specified in DCE).
- Note:
- The USER_OBJ ACLE type is principally supported for purposes of
POSIX compliance (especially, for POSIX-compliant filesystems). Its
utility for most other applications is minimal-indeed,
some authorities believe its use should in general be deprecated.
-
USER or U (with a Principal Tag UUID)
Establishes permissions for the principal identified by the ordered
pair <Default Cell UUID, Principal Tag UUID>, to which the
USER ACLE is said to refer.
-
GROUP_OBJ or GO (no Tags)
Establishes permissions for the object's owning group (in the
POSIX sense), identified by the ordered pair <Default
Cell UUID, Owning Group UUID>, to which the GROUP_OBJ ACLE is said to
refer. The Owning Group UUID is a UUID determined in an
application-specific way (not specified in DCE).
- Note:
- The GROUP_OBJ ACLE type is principally supported for purposes of
POSIX compliance (especially, for POSIX-compliant filesystems). Its
utility for most other applications is minimal-indeed,
some authorities believe its use should in general be deprecated.
-
GROUP or G (with a Group Tag UUID)
Establishes permissions for the group identified by the ordered
pair <Default Cell UUID, Group Tag UUID>, to which the GROUP ACLE
is said to refer.
-
OTHER_OBJ or O (no Tags)
Establishes permissions for all principals and groups in the cell
identified by the ACL's Default Cell UUID, to which the
OTHER_OBJ ACLE is said to refer.
-
Foreign ACLE types
Refer to subjects in foreign cells ("foreign" in the sense of
ACLs has the commonsense meaning of referring to cells
other than the ACL's default cell; that is, that
the Cell Tag UUIDs of foreign ACLE types are distinct from the ACL's
Default Cell UUID. However, it is not forbidden for an ACLE to contain
a Cell Tag UUID which is equal to the ACL's Default Cell UUID-it
is just inefficient to do so):
-
FOREIGN_USER or FU (with a Cell Tag UUID and a Principal Tag
UUID)
Establishes permissions for the principal identified by the
ordered pair <Cell Tag UUID, Principal Tag UUID>, to which the
FOREIGN_USER ACLE is said to refer.
-
FOREIGN_GROUP or FG (with a Cell Tag UUID and a Group Tag UUID)
Establishes permissions for the group identified by the ordered
pair <Cell Tag UUID, Group Tag UUID>, to which the FOREIGN_GROUP
ACLE is said to refer.
-
FOREIGN_OTHER or FO (with a Cell Tag UUID)
Establishes permissions for all principals and groups identified by
the Cell Tag UUID, to which the FOREIGN_OTHER ACLE is said to refer.
-
Universal ACLE type
Refers to subjects in the ACL's default cell or in foreign cells:
-
Mask ACLE types
Used as masks (subtracting rights at most, not adding them)
in the access determination algorithm:
-
MASK_OBJ or M (no Tags)
Masks all ACLEs except USER_OBJ and OTHER_OBJ.
- Note:
- The MASK_OBJ ACLE type is principally supported for purposes of
POSIX compliance (especially, for POSIX-compliant filesystems). Its
utility for most other applications is minimal-indeed,
some authorities believe its use should in general be deprecated.
-
UNAUTHENTICATED or UN (no Tags)
Masks all ACLEs in an "unauthenticated" access request (that is,
one whose PAC has a FALSE authentication flag).
- Note:
- The UNAUTHENTICATED ACLE type is principally supported for purposes of
"system level" applications (for example, "bootstrapping" the system).
Its utility for most other applications is minimal-indeed,
some authorities believe its use should in general be deprecated.
-
Extended ACLE type
Used as a compatibility aid, and does not appear directly in
the access determination algorithm:
-
EXTENDED or E (no Tags)
A special type for ensuring extensibility/compatibility of the ACL mechanism.
The intent is that if a new version of a server supports ACLE types that
were not supported in earlier versions, then the new server is supposed
to convert said new ACLE types to the EXTENDED type before passing ACLs
back to old clients (via
rdacl_lookup()
-see
ACL Editors
).
-
Delegation Local ACLE types
Refer to subjects in the ACL's default cell:
-
USER_OBJ_DELEG or UOD (no Tags)
Establishes permissions for the object's owning user (in the
POSIX sense) acting as a delegate, identified by the ordered pair <Default Cell UUID,
Owning Principal UUID>, to which the USER_OBJ_DELEG ACLE
is said to refer.
The Owning Principal UUID is a UUID determined in an
application-specific way (not specified in DCE).
- Note:
- The USER_OBJ_DELEG ACLE type is principally supported for purposes of
POSIX compliance (especially, for POSIX-compliant filesystems). Its
utility for most other applications is minimal-indeed,
some authorities believe its use should in general be deprecated.
-
USER_DELEG or UD (with a Principal Tag UUID)
Establishes permissions for the principal acting as a delegate identified by
the ordered pair <Default Cell UUID, Principal Tag UUID>, to which the
USER_DELEG ACLE is said to refer.
-
GROUP_OBJ_DELEG or GOD (no Tags)
Establishes permissions for the object's owning group (in the
POSIX sense) acting as a delegate, identified by the ordered pair <Default
Cell UUID, Owning Group UUID>, to which the GROUP_OBJ_DELEG ACLE is said to
refer. The Owning Group UUID is a UUID determined in an
application-specific way (not specified in DCE).
- Note:
- The GROUP_OBJ_DELEG ACLE type is principally supported for purposes of
POSIX compliance (especially, for POSIX-compliant filesystems). Its
utility for most other applications is minimal-indeed,
some authorities believe its use should in general be deprecated.
-
GROUP_DELEG or GD (with a Group Tag UUID)
Establishes permissions for the group acting as a delegate identified by
the ordered pair <Default Cell UUID, Group Tag UUID>, to which the GROUP_DELEG ACLE
is said to refer.
-
OTHER_OBJ_DELEG or OD (no Tags)
Establishes permissions for all principals acting as a delegate
in the cell identified by the ACL's Default Cell UUID, to which the
OTHER_OBJ_DELEG ACLE is said to refer.
-
Delegation Foreign ACLE types
Refer to subjects in foreign cells acting as a delegate ("foreign"
in the sense of ACLs has the commonsense meaning of referring to cells
other than the ACL's default cell; that is, that
the Cell Tag UUIDs of foreign ACLE types are distinct from the ACL's
Default Cell UUID. However, it is not forbidden for an ACLE to contain
a Cell Tag UUID which is equal to the ACL's Default Cell UUID-it
is just inefficient to do so):
-
FOREIGN_USER_DELEG or FUD (with a Global Principal Tag UUID)
Establishes permissions for the principal acting as a delegate
identified by the <Global Principal Tag UUID>,
to which the FOREIGN_USER_DELEG ACLE is said to refer.
-
FOREIGN_GROUP_DELEG or FGD (with a Global Group Tag UUID)
Establishes permissions for the group acting as a delegate identified by
the <Global Group Tag UUID>, to which the FOREIGN_GROUP_DELEG
ACLE is said to refer.
-
FOREIGN_OTHER_DELEG or FOD (with a Cell Tag UUID)
Establishes permissions for all principals acting as a delegate
identified by the Cell Tag UUID, to which the FOREIGN_OTHER_DELEG ACLE is
said to refer.
-
Delegation Universal ACLE type
Refers to subjects in the ACL's default cell or in foreign cells:
There are a few conditions that an ACL must satisfy in order to be
considered (absolutely) well-formed. For example, a well-formed
ACL must not contain more than one USER ACLE that refers to a given
principal. These "formation rules" are given in detail in
Access Control Lists (ACLs)
.
Object Types, ACL Types, and ACL Inheritance
Resource managers in general (and, by extension, reference monitors)
distinguish between two types of objects: container objects and
simple objects. (In general the unqualified word "object" refers
to either container or simple objects, but when the context requires
just one of these types, plain "object" means a simple object.)
Container objects "contain" (in some application-defined sense,
often reflected in a hierarchical name structure) other objects
(simple or container).
Simple objects do not contain other objects.
The words parent and child are used to express the
relationship between containers and the objects contained
in them, respectively. Examples of container objects might include a
filesystem directory or a database table; examples of simple objects
might include a file or a database entry.
Not all resource managers need support container objects.
To protect both simple and container objects, and to enable newly
created objects to automatically inherit default ACLs from their
parent container objects (a usability criterion), the ACL facility
supports two ACL types (this is to be distinguished from the ACL's
manager type, defined in
Access Control Lists (ACLs)
):
-
Protection (or Object) ACLs are associated with
either simple or container objects, and control access to them (that
is, figure into the access determination algorithm exercised by ACL
Managers (see below)).
- Note:
- By abuse of language, when one speaks of "the" ACLs associated
with protected objects, it is always the Protection
ACLs that are meant, unless explicitly indicated otherwise.
-
Initial (or Default Creation) ACLs are associated
with container objects only. Their function is not to control access to
the container, but rather to supply default values for the ACLs
inherited by child objects (both simple objects and containers) when
they are initially created in the container. There are two kinds of
Initial ACLs:
-
Initial Object ("IO") ACLs
Supplies default values for Protection ACL of simple child objects,
and for the IO ACL of container child objects.
-
Initial Container ("IC") ACLs
Supplies default values for the Protection ACL and the IC ACL of
container child objects.
Thus, in this inheritance model, simple objects have only one ACL
associated with them (a Protection ACL), while container objects have
three ACLs associated with them (Protection, IO and IC ACLs). And the
creation of (simple and container) child objects obeys the following
ACL Inheritance Rules:
-
When a simple child object is created in a parent container, the child
inherits, by default, the parent's IO ACL as the child's Protection ACL.
(But if an ACL is specified, it overrides this default.)
-
When a child container is created in a parent container, the child
inherits, as defaults, the parent's IC ACL as the child's Protection
ACL, and the parent's IO and IC as the child's IO and IC ACLs,
respectively. (But if any of these ACLs are specified, they override
the corresponding default.)
Other than the distinctions described above, there are no differences
between the Protection ACL and Initial ACL types-therefore, the
information about ACLs in the rest of this section does not
differentiate between ACL types.
ACL Managers, Permissions, Access Determination Algorithms
ACL Managers are the modules within RPC servers that interpret (that
is, lend semantics to) ACLs. Namely, every ACL Manager is identified
within a server by a UUID called the ACL Manager's type UUID, and
a given ACL Manager can interpret a given ACL if and only if the ACL
Manager's type UUID is the same as the ACL's ACL Manager Type UUID (the
latter is defined in
Access Control Lists (ACLs)
).
- Note:
- Different ACL Managers-that is, those having different
type UUIDs-can share the same executable code.
This notion of interpreting an ACL manifests itself in the following
areas:
-
ACLs and ACLEs
An ACL Manager need not support all possible absolutely well-formed
ACLs (where "absolute" refers to the general ACL Facility),
but may define its own notion of relatively well-formed
ACLs (where "relative" refers to the specific ACL Manager itself)
-but the ACLs that it does support must be well defined.
As an example, an ACL Manager need not support all the ACLE types
supported by the ACL Facility itself (for example, an ACL Manager
that never grants access to unauthenticated requests need
not support the UNAUTHENTICATED ACLE). As another example, an ACL
Manager might require that a certain "minimal" configuration of ACLEs is
present in every ACL it supports (for example, a USER_OBJ/GROUP_OBJ/OTHER_OBJ
triple, or at least one ACLE that grants Control ("Write-ACL")
permission (see below)).
(Also, not all ACL Types (Protection, IO, IC)
and their Inheritance Rules as specified in
Object Types, ACL Types, and ACL Inheritance
need be supported-but that is a property of the server as a whole,
not a property of a specific ACL Manager.)
-
Permissions
The meanings of the permissions to protected objects vary according
to the ACL Manager type associated with the ACL.
Permissions themselves are considered to be "primitives", and access
requests are determined (granted or denied) on the basis of
combinations ((unordered) sets) of these primitives. In DCE,
permissions are implemented as bits (represented as integers
2i for 0 <= i <= 31), and combinations of
them as bit-vectors (represented as integers in the range
[0, 232-1]). The number of permissions supported by an
ACL Manager can be any number between 1 and 32 inclusive. (DCE
does not support ACL Managers having 0 permissions; objects protected by
more than 32 permissions can be supported by protecting them with
multiple ACLs, each having a distinct ACL Manager Type-see
Multiple ACLs and ACL Managers
.)
-
Printstrings and Helpstrings
To each permission it supports, an ACL Manager associates,
for human consumption, a printstring identifying the permission,
as well as a helpstring that further explains the semantics of
the permission.
These strings are relayed to users by ACL Editors, as discussed above.
-
Access Determination Algorithm (or Authorisation Decision
Computation)
The algorithm that takes as input a principal's
PAC, an object's ACL, and an access request, and returns as output a
judgement whether the server should grant or deny the
access, is implemented by the ACL Manager.
In principle, there can be many distinct classes of ACL Managers,
implementing the above areas in different application-specific
ways (consistent with the security requirements of application servers).
DCE currently defines (below) one distinguished class of
ACL Managers, namely, the so-called Common ACL Managers.
However, no strict rules of
the form "DCE-conformant ACL Managers must be Common ACL Managers"
(or for that matter, ACL managers of any other type)
are specified in DCE. Thus, the notion of Common ACL Manager may
be considered merely to be a suggestive example.
Furthermore, other classes of ACL Managers (other than Common ACL
Managers) may be defined in future revisions of DCE.
(On the other hand, applications that can support their security
requirements by implementing Common ACL Managers may be well-advised to
do so-it is a desirable "user-friendliness" issue for users to
find such a level of consistency amongst all the ACL managers in all the
applications throughout their environment.)
Common ACL Managers are defined as follows:
-
ACLs and ACLEs
Common ACL Managers support at least the USER, GROUP, OTHER_OBJ,
FOREIGN_USER, FOREIGN_GROUP, FOREIGN_OTHER and ANY_OTHER ACLEs.
(Thus, Common ACL Managers need not, but may, support the USER_OBJ,
GROUP_OBJ, MASK_OBJ, UNAUTHENTICATED or EXTENDED ACLEs.)
Concerning ACL Types and their Inheritance Rules (which are
within the scope of the server as a whole, not of a specific ACL
Manager): if a Common ACL Manager supports both simple objects and
containers, then it supports all the ACL Types (Protection, IO, IC),
with their Inheritance Rules as specified in
Object Types, ACL Types, and ACL Inheritance
.
-
Permissions and printstrings
There are 7 permission bits that are distinguished by the ACL Facility,
with respect to their (C-language) names, values (bit
representations) and printstrings (see
Common Permissions
and
Common Printstrings
;
for recommended helpstrings, see
Common Helpstrings
).
However, the generic ACL Facility itself does not specify the access
semantics of those permissions-that is the responsibility of
individual ACL managers themselves.
In the case of Common ACL Managers, those semantics are described in the
following list, wherein the 7 distinguished permissions are identified
by their "colloquial" names (in English).
(Thus, Common ACL Managers that support permissions having semantics as
described in the following list use the bit representation and
printstring associated with them (as specified in
Common Permissions
and
Common Printstrings
),
and those bit representations and printstrings are not used for
any other permission semantics; however, Common ACL Managers need not
support all seven of these permission semantics, nor are they
limited to supporting only these seven permission semantics.)
-
Read
Disclose information associated with the protected object.
-
Write
Modify information associated with the protected object.
-
Execute
Cause a processing element to deliver service associated
with the protected object.
-
Control (or Change or Write-ACL)
Modify the ACL itself (as for protected object), thereby
"controlling" access to the object protected by the ACL.
Typically, "owners" (in some site- or application-specific sense) of
protected objects are given control access to the object's ACL. (See
rdacl_replace().)
- Note:
-
DCE does not specify how Common ACL Managers manage
disclosure of ACLs (Read-ACL access), so that aspect of
Common ACL managers remains implementation-specific. One possible
solution is to support it with a permission, similar to the Control
permission. Another solution (the most typical one, and the one
suggested by DCE) is to grant Read-ACL access to any
principal to which the ACL grants any access whatsoever (according
to the Common Access Determination Algorithm described below). (This
type of "any access" is not represented by a "permission" supported
by the ACL Manager, so is an exception to the "rule" that Common ACL
Managers mediate all access to protected objects (such as the ACL
itself) via the Common Access Determination Algorithm (below).) The
POSIX solution (which contemplates only filesystems, and only in a
non-distributed environment) is to grant Read-ACL access to any
principal that is granted "POSIX search" access to the hierarchy of
(filesystem) directories containing the object (file) in question (but
not necessarily the object itself). (See
rdacl_lookup()
and other operations in
ACL Editors
.)
-
Insert
Insert objects into the protected container object.
-
Delete
Delete objects from the protected container object.
-
Test
Compare a presented value to a value associated with
the protected object, without disclosing its actual value. For
example, compare a presented password with an actual password (though
this isn't the way DCE supports password-based authentication).
-
Access Determination Algorithm
Common ACL managers support the Common Access Determination Algorithm
specified in the next section.
- Note:
-
DCE does not currently specify an ACL Manager API (although it is
envisioned that one will be supported in a future revision).
Typically, implementations will support (implementation-dependent)
ACL Manager APIs with routines that support the server's rdacl
RPC interface (see
ACL Editors
).
The Common Access Determination Algorithm for Delegation
As of DCE 1.1,
Common ACL Managers support the Common Access Determination Algorithm,
as described in this section (and specified carefully in
ACL Managers
).
This is the algorithm that is executed by a Common ACL Manager upon an access
request. The output of the algorithm consists of a judgement whether
the server should "grant" or "deny" access to the protected object.
Prior to DCE 1.1, Common ACL Managers needed only to ensure secure
operations between two principals, typically described as a client and
a server.
As of DCE 1.1, clients and servers are able to invoke secure operations
through one or more intermediaries.
The Common Access Determination Algorithm has been modified as of
DCE 1.1 in order to verify that the privilege attributes for each principal
involved in the operation have the necessary rights in order to support
delegation. This is because, for delegation, there is a delegation chain
consisting of the intermediaries involved in servicing the requested
operation.
The order of intermediaries is not considered significant (for access
determination-order is important in terms of certification,
for instance. See
Further Discussion of Certification
for further discussion on this subject).
The input to the algorithm consists of:
-
An EPAC (presented from the client to the server, via a protected RPC).
This EPAC contains the identity and group membership information present
in a DCE 1.0 format PAC.
This EPAC also contains the privilege attributes of each participant
(principal) in the chain.
- Note:
- For compatibility with DCE 1.0, a PAC may be generated from an EPAC
(by the Privilege Server, PSZ, and be transmitted in the A_D
field of a ticket (PTGT). Thus, existing legacy authorization models
will continue to work.
-
The principal involved in the operation, for each principal involved
in the EPAC.
- Note:
- The order of intermediaries is not considered significant. Thus, the
order of the checking of principals is not specified, and has no
effect upon the standard access algorithm.
-
Privilege Attribute Set for each principal involved in the operation.
This Privilege Attribute Set is contained within the EPAC.
-
An ACL, having the ACL manager type UUID of the invoked Common ACL Manager,
and containing a list of ACLEs with types and tags as described above.
(Note that a single ACL can represent at most 32 distinct permissions,
because a single ACL can be associated with only a single ACL
manager type UUID. The case of more than 32 permissions is dealt with in
Multiple ACLs and ACL Managers
.)
-
An access request (of "required permissions"), which is considered
to be a non-empty subset of the permissions supported by the
ACL Manager.
(The case of an empty access request is not specified by DCE; it
is implementation-specific.)
Common ACL Manager Algorithm
Given this input, the Common ACL Manager grants or denies access according to
Common Access Determination Algorithm
(of the ACLEs of the ACL in question), which affords a memorisable mental
image of the common access determination algorithm.
Figure: Common Access Determination Algorithm
In words,
Common Access Determination Algorithm
is to be interpreted as follows (this description is a loose paraphrase
of the common access determination algorithm which is specified in detailed
pseudocode in
ACL Managers
):
-
Match (in the sense defined in the pseudocode in
ACL Managers
)
the incoming PAC against the ACL's access ACLEs (in the
top-to-bottom order shown, namely: UO, U, FU, GO/G/FG, O, FO, AO), stopping
at the first such match (except that all matches are considered
"simultaneously" in the case of the indicated group-like ACLEs),
and note the permissions granted by the matched ACLE (or, in the
case of the group-like ACLEs, the union of the permissions
granted by all the matched ACLEs).
-
Mask (that is, intersect) the acquired permissions against the
permissions in the ACL's mask ACLEs, as necessary
(namely, mask with MASK_OBJ permissions if the match occurred in the
center column, and/or mask with UNAUTHENTICATED permissions if the
PAC is unauthenticated). (If the ACL Manager doesn't support these
two mask ACLEs, this step is a null operation.)
- Note:
- While this mental image shows incoming PACs, it is applicable to EPACs
as well-in particular, for the initiator of a request.
Intermediaries use the algorithm whose mental image is given in
Delegation Common ACL Manager Algorithm
.
Delegation Common ACL Manager Algorithm
Given the input specified in
The Common Access Determination Algorithm for Delegation
,
the Common ACL Manager grants or denies access according to
Delegation Common Access Determination Algorithm
(of the ACLEs of the ACL in question), which affords a memorisable mental
image of the delegation common access determination algorithm.
This algorithm for delegation operates upon a set of extended entries
in the ACL that apply only to principals acting as intermediaries.
These extended entries permit intermediaries to be listed on the ACL
without granting those intermediaries the ability to operate on the
target object directly. Without these extensions, an intermediary
would be otherwise be granted the ability to perform the operation
requested of their own initiative.
- Note:
- In this figure, the standard ACL entries are extended with entries
identifying the abilities of the intermediary. The entries are
traditionally extended with the _DELEGATE specification.
However, in this mental image, they have been shortened to _DEL.
Figure: Delegation Common Access Determination Algorithm
In words,
Delegation Common Access Determination Algorithm
is to be interpreted as follows (this description is a loose paraphrase
of the common access determination algorithm which is specified in detailed
pseudocode in
ACL Managers
):
-
Match (in the sense defined in the pseudocode in
ACL Managers
)
the incoming EPAC against the ACL's access ACLEs (in the
top-to-bottom order shown, namely: UOD, UD, FUD, GOD/GD/FGD, OD, FOD, AOD),
stopping
at the first such match (except that all matches are considered
"simultaneously" in the case of the indicated group-like ACLEs),
and note the permissions granted by the matched ACLE (or, in the
case of the group-like ACLEs, the union of the permissions
granted by all the matched ACLEs).
-
Mask (that is, intersect) the acquired permissions against the
permissions in the ACL's mask ACLEs, as necessary
(namely, mask with MASK_OBJ permissions if the match occurred in the
center column, and/or mask with UNAUTHENTICATED permissions if the
EPAC is unauthenticated). (If the ACL Manager doesn't support these
two mask ACLEs, this step is a null operation.)
Notes on Common ACL Manager ACLs
- Notes:
-
In the case of Common ACL Managers that support only "relatively
well-formed" ACLs (such as, for example, ACL Managers that do not
support MASK_OBJ), some simplifications of the two figures above and (or)
the pseudocode description in
ACL Managers
may be possible (for example, by omitting some ACLEs from the diagram,
or rearranging some clauses of the algorithm).
But such simplifications could lead to confusion, and should be
avoided, as the diagram and pseudocode as presented are fully
general enough to encompass all Common ACL Managers.
-
The access model supported by DCE is "object-based", as opposed to
"name-based", in the sense that it depends only on the ACL of the
target object, not those of intermediate naming nodes used to specify
the object.
This is in contradistinction to certain other systems, notably POSIX,
whose access semantics support a notion of "pathname resolution",
whereby a "search" ("traverse") permission is required of
intermediate naming nodes in addition to the access permissions of the
ultimate target (leaf) object.
Multiple ACLs and ACL Managers
It is a typical scenario for a server to support only a single
(protection) ACL per protected object, and a single ACL Manager to
interpret the ACLs on all protected objects.
But it is entirely conceivable that a server may support more than one
ACL and/or ACL Manager. The following are some of the scenarios where
this is useful or necessary:
-
Multiple types of protected objects
If a server supports multiple types of protected objects, it should
(or rather, "must", since this is virtually the definition of
"type of protected object")
support a different ACL Manager type for each type of protected object.
An example of this is given by the RS server itself (which supports five
types of protected objects)-see
ACL Manager Types Supported by the RS
.
-
More than 32 permissions
If a server supports more than 32 permissions, then since each ACL and
each ACL Manager can support at most 32 permissions, the server must support
multiple ACLs and ACL managers. Conceptually, all such ACL Managers would
support exactly the same access determination algorithm (perhaps even
sharing the same code), but the interpretation of the permission
bits would differ among the ACL Managers.
Colloquially speaking, "bit i (that is, 2i,
for 0 <= i <= 31)
means something different for ACL Manager Type UUID1 than it
does for ACL Manager Type UUID2." For example, a given
server might protect its objects with ACLs having a (hypothetical)
"Search" permission mapped to bit 27 of ACL Manager Type
UUID1 and an "Append" permission mapped to bit 27 of
ACL Manager Type UUID2. An access request that required
only, say, Search permission would then have to query only one ACL, while
a request requiring both Search and Append permissions would have to
query two ACLs (exactly the same ACL Manager code could potentially be
used for both checks, but that's an implementation choice).
At the extreme, a server could even support only a
single permission bit per ACL Manager (leaving the other 31 bits
unused), thereby effecting a one-to-one mapping between its protected
object's permission bits and UUIDs (the latter coming from the ACL
Manager's Type UUID).
-
Exotic combinations
Some servers may need to query multiple quite different ACLs, some
application-specific combination, to determine access; the potential
combinations are unbounded in number.
A simple example is afforded by the RS server itself, whose deletion
operation
(.Fn rs_pgo_delete
-see
rs_pgo_delete()
)
checks both the ACL of the object to be deleted as well as the ACL of the
parent container of that object.
Variations on the ACL and ACL Manager architecture along these lines
will be taken for granted in the remainder of this specification,
and will not be mentioned explicitly again.
Protected RPC
As discussed above, the KDS and PS identify subjects to one another
(including communicating privilege information), and perform session
key management.
Once a client and server share a session (or conversation) key, they can
communicate "application-level" data securely.
The protection level that an application may set using
RPC determines the level of security of network messages.
- Note:
-
Part of the rationale for supporting a range of protection options is that,
as a rule, higher security has an inversely proportional relationship to
performance (because of the cost of code paths that go through security
code, especially encryption/decryption and cryptographic checksum
checking). The RPC facility provides several levels of protection so
that applications can control this tradeoff between security and
performance.
Following are the supported protection levels, arranged in order of
"increasing" protection.
The exact interpretation of these descriptions is dependent on
underlying RPC and transport protocols (as specified in the referenced Open Group DCE 1.1 RPC Specification),
and is given in
Protected RPC
.
-
rpc_c_protect_level_none
No security guarantees.
This amounts to the client and server receiving mere "assertions"
(of low trustworthiness) about security attributes, as opposed to
more convincing evidence of their trustworthiness (namely,
TCB cryptographic protection).
"Protected RPC" of this protection level is also called
unprotected RPC.
-
rpc_c_protect_level_connect
Mutual authentication established when client and server initially
establish a session.
-
rpc_c_protect_level_call
Mutual authentication established at the initiation of every
RPC call between client and server.
-
rpc_c_protect_level_pkt
Mutual authentication established for every packet (unit of
communication, as interpreted by underlying RPC and transport
protocols) between client and server.
-
rpc_c_protect_level_pkt_integ
rpc_c_protect_level_pkt protection plus integrity protection
of every packet (in the rpc_c_authn_dce_secret regime,
this integrity protection is achieved with DES and MD5).
-
rpc_c_protect_level_pkt_privacy
rpc_c_protect_level_pkt_integ protection plus confidentiality
protection of every packet (in the rpc_c_authn_dce_secret
regime, this confidentiality protection is achieved with DES).
ACL Editors
Clients that manipulate a server's ACLs as data (as distinguished from
clients that only use ACLs as metadata; that is, clients that only
access the underlying objects that the ACLs actually
protect), are called ACL Editors.
The API that ACL Editors call is the sec_acl API, and the RPC
interface that RPC servers export to support the sec_acl API is
the rdacl RPC interface.
For the purposes of the rdacl interface, ACLs are identified by a
combination of 4 items:
-
The identity of the protected object itself.
This is identified by:
-
the identity of the server managing the protected object, and
-
a server-supported stringname that "further identifies" the
protected object within the server.
-
The identity of the specific ACL associated with the protected object.
This is given by:
-
its ACL manager UUID, and
-
its ACL type.
The server-supported stringname, in particular, enables the possibility
of extending the naming model, so that protected objects "appear
as named objects in the (combined CDS-supported and server-supported)
namespace"-and this is how the sec_acl API views protect
objects. (Concerning CDS, see the referenced Open Group DCE 1.1 Directory Services Specification.)
This is especially useful for servers that support large
numbers of protected objects (though its use is "optional," in the
sense that servers can register each protected object solely via a
server name in the CDS and an empty server-supported stringname, if they
so wish). In the extended naming model, a server registers its own RPC
binding name and an RPC object UUID in the usual way (with the CDS and
with the local Endpoint Map)-the RPC object UUID (only one such
should be registered in a given CDS namespace server entry) represents
the "root" of the (server-supported) namespace (which may be
hierarchical or not, and may have a different syntax from the CDS
namespace).
An ACL Editor can then address protected objects (and their
ACLs) by uttering a pair of names: the server's CDS-registered
name and the server-supported name of the protected object. It is even
possible to view this pair of names as a single (syntactically
concatenated) name, provided that the naming service in which the server
is registered supports a resolution-with-residual support
operation (that is, the namespace server resolves the concatenated name up
to the server's registration point, returning to the client the
resolved (parsed) and residual (unparsed) parts of the
name). This enables the client to query the namespace at the resolved
name for the server's registered binding information, and then to bind to
it and present to it the server-supported part of the name.
(The CDS name servers do support such a resolution-with-residual
operation-see
rpc_ns_entry_inq_resolution();
potentially, the two steps of resolution-with-residual and binding-query
could be combined into a single operation.)
Note that this describes a general mechanism, called
the namespace junction (or federated naming) model,
whose utility is not limited to ACL editing. This is illustrated in
Namespace Junction (Federated Naming) Model
(where hierarchical namespaces are illustrated using abstract
ordered tuples of nodes, but for simplicity their concrete syntaxes are
not shown). (For an example of junctions, see
Registration Service (RS) and RS Editors
,
which discusses the RS's own use of this naming model.)
Figure: Namespace Junction (Federated Naming) Model
The rdacl RPC interface consists of the following operations:
-
rdacl_get_manager_types()
Obtain a list of ACL manager types protecting an object.
-
rdacl_get_mgr_types_semantics()
Obtain a list of ACL manager types protecting an object, together with
information about the semantics they support.
-
rdacl_get_printstring()
Obtain human-readable representations of permissions supported by an ACL
manager.
-
rdacl_lookup()
Retrieve (that is, "read") ACLs on a protected object, creating a copy
locally on the client. ACL modification is done by manipulating the local
copy, then applying this to the remote protected object with
rdacl_replace().
-
rdacl_replace()
Apply (that is, "write") ACLs to a protected object. This replaces the
currently existing ACL on the protected object with a new one.
- Note:
-
The "currently existing ACL" that gets replaced by an invocation of
rdacl_replace()
might not be the same as the "old ACL" that was previously retrieved by
rdacl_lookup(),
because of a race condition: an intervening
rdacl_replace()
from another client may have already replaced that old ACL on the protected
object by a different ACL (that is, no locking/transactional semantics are
supported to prevent this from happening). In fact, an
rdacl_replace()
may even fail if an intervening
rdacl_replace()
installs an ACL that denies the necessary control permission.
This potential for interleaved
/.Fn/.Fn()rdacl_replace
may be a minor inconvenience for some applications,
but it is not typically a major inconvenience because it is rare for
multiple clients to be managing the same ACL at the same time.
In any case, this race condition does not compromise security
(because every client's authority to manage ACLs is always checked,
via the ACL's control permission), nor does it compromise
consistency (because
rdacl_replace()
is atomic, writing whole ACLs at a time).
-
rdacl_get_access()
Obtain calling principal's permissions to a protected object.
-
rdacl_test_access()
Determine whether calling principal has the specified permission to
access a protected object.
-
rdacl_test_access_on_behalf()
Determine whether a specified principal (not necessarily the calling
principal) has the specified permission to access a protected object.
This can be used to support a primitive form of delegation.
-
rdacl_get_referral()
Obtain a referral to an ACL "update site" (that is, a server instance or
replica that manages a writable copy of the ACL, as opposed to a read-only
copy).
This operation can be used to support server replication (of a simple
type).
The sec_acl API consists of the following routines:
-
sec_acl_bind()
Obtain a "protected object handle" (that is, a handle referring to
a protected object, represented by the sec_acl_handle_t
data type), identifying the protected object by full name (that is,
by CDS namespace entry concatenated with a
server-supported namespace name). ACLs themselves are identified by a
combination of this handle, the manager type UUID of the ACL, and the
type of the ACL (protection, object creation or container creation).
-
sec_acl_bind_to_addr()
Identical to
sec_acl_bind(),
except that the protected object in question is identified by a
combination of the address of the server and a server-supported
namespace name.
-
sec_acl_release_handle()
Release protected object handle previously created by
sec_acl_bind()
or
sec_acl_bind_to_addr().
-
sec_acl_get_manager_types()
Obtain a list of ACL manager types (UUIDs) protecting an object.
(Layered over
rdacl_get_manager_types().)
-
sec_acl_get_mgr_types_semantics()
Obtain a list of ACL manager types protecting an object, together with
information about the semantics they support. (Layered over
rdacl_get_mgr_types_semantics().)
-
sec_acl_get_printstring()
Obtain human-readable representations of permissions supported by an ACL
manager. (Layered over
rdacl_get_printstring().)
-
sec_acl_lookup()
Retrieve ("read") ACLs on a protected object. (Layered over
rdacl_lookup().)
-
sec_acl_replace()
Apply ("write") ACLs to a protected object. (Layered over
rdacl_replace().)
-
sec_acl_release()
Free (local copy of) ACLs previously created by
sec_acl_lookup().
-
sec_acl_get_access()
Obtain calling principal's permissions to a protected object.
(Layered over
rdacl_get_access().)
-
sec_acl_test_access()
Determine whether calling principal has the specified permission to
access a protected object. (Layered over
rdacl_test_access().)
-
sec_acl_test_access_on_behalf()
Determine whether another principal has the specified permission to
access a protected object. (Layered over
rdacl_test_access_on_behalf().)
-
sec_acl_get_error_info()
Obtain DCE runtime support routine error information related to the
sec_acl API.
-
sec_acl_calc_mask()
Calculate a new MASK_OBJ ACLE for an ACL (or list of ACLs), whose
permissions are the union of the permissions of all ACLEs of types USER,
FOREIGN_USER, GROUP_OBJ, GROUP, FOREIGN_GROUP, FOREIGN_OTHER, ANY_OTHER.
- Notes:
-
-
The
sec_acl_calc_mask()
routine is supported for POSIX-compliant applications; that is, those
that support MASK_OBJ with its POSIX semantics. The set of ACLEs
listed, of which the newly calculated MASK_OBJ is the union, corresponds
approximately to what POSIX calls the "File Group Class ACLEs",
though that designation is inappropriate in the context of DCE.
-
The sec_acl API is designed to be a general programming interface
for managing all ACLs in such a way that the client is unaware of the
principal identity of the server that controls the objects protected by
the ACLs.
As such, the server's principal name does not occur as a parameter to
the sec_acl API (see, for example,
sec_acl_bind()).
This implies, in particular, that the sec_acl API supports only
one-way (client-to-server) authentication, not mutual
(server-to-client) authentication. Applications that require mutual
authentication should use the "raw" rdacl RPC protocol, not the
sec_acl API. (Mutual authentication may be added to the
sec_acl API in a future revision of DCE.)
-
No local "high-level ACL manipulation" API routines are currently supported
(for example, "add or delete such-and-such an ACLE from this ACL", or
"deny all privileges for such-and-such a principal").
Such operations are typically supported by interactive command-level ACL
editing user interfaces, but those are beyond the scope of this revision
of DCE.
Registration Service (RS) and RS Editors
The Registration (or Registry) Service (RS) is the
TCB's repository for security-relevant data (in particular,
identities, long-term cryptographic keys and privilege information)
in DCE.
The RS maintains a datastore, whose clients are the KDS and PS,
and RPC interfaces for the RS Editor, ID Map and Key Management
facilities (see
DCE Security Model
).
The stored elements of the RS datastore are here
called items-not objects, to distinguish terminologically
between "the entities themselves" ("objects") and the
datastore information ("items" with "attributes" attached to them)
stored about the objects. Certain collections of items are called
domains. The items in the RS datastore are organised into the
following five categories:
-
(RS) Policy Item
Contains cell-wide information applicable to all the
entities in the cell (not just, for example, principals in a particular
organisation or group within the cell-not to be confused with
"organisation policies", below).
The Policy item has two categories of attributes, respectively called
(Registry) policies and (Registry) properties.
-
Principal (P) Domain
Contains principal items; that is, information about principals
(or "principal objects").
Each principal is normally associated with an account (see below).
-
Group (G) Domain
Contains group items; that is, information about groups (or "group
objects"). Each group is associated with an (unordered) set of principals
(not, however, of other groups), called the members of the group.
-
Organisation (O) Domain
Contains organisation items; that is, information about
organisations (or "organisation objects").
Each organisation is associated with an (unordered) set of principals
(not, however, of groups or other organisations), called the
members of the organisation. Organisations have as attributes
organisation policies.
-
Account Domain
Contains account items; that is, information about accounts (or
"account objects"). Accounts identify the targets of DCE login
rituals (see the Login Facility, below). They consist of a triplet,
consisting of principal, group, and organisation items.
Principals (and other entities, such as groups and organisations) whose
security data is held in a cell's RS are said to belong to
that cell (in the security sense at least, and
usually in the administrative sense also); similarly, the
protected objects that server principals act as reference monitors for
are said to belong to the server principal's cell.
The RS itself has the principal name dce-rgy (within its cell).
Programs that manipulate (for administrative purposes) the RS datastore are
called RS Editors (or Rgy Editors). To support RS Editors,
the RS supports the rs_policy, rs_pgo and rs_acct
RPC interfaces, described below. (The RS also supports additional
RPC interfaces for other uses, and these are introduced in context in other
sections.)
- Note:
-
In the current revision of DCE, the only RS Editor APIs that are
supported are those related to binding to RS servers-that is, the
RS Editor RPC interfaces supported by DCE are not currently
supported by corresponding APIs. It is anticipated that such APIs
will be added in a future revision.
ACL Manager Types Supported by the RS
The RS is the only service in the DCE TCB that supports a
datastore of persistent items, and is the only one (not counting DTS)
that protects its objects with ACLs (the KDS and PS protect the objects
they manage by direct cryptographic means, not with ACLs).
This section briefly discusses RS ACL management (an extended
discussion occurs in
RS Protected Objects and their ACL Manager Types
).
The RS acts as the reference monitor to five kinds of protected objects
(items in its datastore), supported by five Common ACL Manager types.
Each of the RS's protected objects is of exactly one of the following
kinds (that is, no item can (currently) be "polymorphic", in the sense of
being of more than one of the following kinds):
-
Policy ACL Manager Type
Manages ACLs on the RS's Policy item.
-
Directory ACL Manager Type
Manages ACLs on directories.
These directories are containers internal to the RS itself, not one
of the items managed by the RS datastore.
-
Principal ACL Manager Type
Manages ACLs on principal items.
-
Group ACL Manager Type
Manages ACLs on group items.
-
Organisation ACL Manager Type
Manages ACLs on organisation items.
The ACL Manager Type UUIDs, the supported permissions
and ACLE Types of these ACL Manager types, and the
printstrings, bit representations and semantics
associated with their supported permissions, are all specified in
RS Editor RPC Interfaces
.
RS Binding; rs_bind Interface and sec_rgy_bind API
This section discusses the RS binding and replication model, and its
corresponding rs_bind RPC interface and sec_rgy_bind API.
These are used to manage RPC bindings (or "contexts") between clients
and (potentially replicated) RS servers, thereby enabling communications
sessions between them.
A basic concept supported by DCE is that of
replication of the RS service.
For the purposes of this replication model, the terms server,
instance, replica and site are considered to be
synonymous. Specifically, the RS replication model supports a
model of replication of the RS datastore consisting of two kinds of
replicas: (one or more) writable (update) servers,
and (zero or more) readable (query) servers,
where every update server is a query server as well.
This model is satisfied by, for example, any of the following:
-
an unreplicated RS server
-
replicated "master/slave" RS servers (one update replica and
multiple query replicas)
-
"mirrored" RS servers (multiple RS servers which support all RS
services and whose datastores are maintained synchronously).
- Note:
- The RPC-level protocols to actually support this replication model
are not specified in this revision of DCE; it
is anticipated that they will be supported in a future revision.
All RS replicas (query or update) export the rs_bind RPC
interface, which supports the following operation:
This
rs_bind_get_update_site()
operation supports the RS Binding and replication models discussed above.
Namely, clients can target query operations to arbitrary replicas; and
they can target update operations to update replicas
whose binding is determined by an invocation of
rs_bind_get_update_site()
(the latter can be targeted to an arbitrary (query or update) replica).
At RPC level, a context with an RS site is represented by an RPC binding
handle, of data type handle_t.
At API level (in the sec_rgy_bind API, and other RS APIs to be
supported in future revisions of DCE), a context is represented
by an RS handle, of data type sec_rgy_handle_t.
The sec_rgy_bind API supports the following routines:
Policy Item, Policies and Properties; rs_policy RPC Interface
The (RS) Policy Item holds Policy and Property
information that affects all accounts in a cell. (This is not to be
confused with Organisation Policies, which affect only the accounts
of principals that are members of a particular organisation.)
-
(Registry) Properties include such information as:
-
The version number of the RS software used to create and read the RS
datastore.
-
The name and UUID of the cell associated with the RS, and whether an RS site
is valid for update ("writable") or only for query ("read-only").
-
Minimum and default lifetimes for tickets issued to principals.
-
Bounds on the local ID numbers used for principals, and whether the
UUIDs of principals also contain embedded local ID numbers.
-
(Registry) Policies and Organisation Policies
control the accounts of principals that are members of the cell or
of an organisation within the cell.
This data controls the lifetime and length of passwords, as
well as the character set from which passwords may be composed. It also
controls the default lifespan of accounts. The policy in effect for any
principal or organisation (said to be its effective policy)
is the most restrictive combination of the cell policy and the policy for
the principal or organisation.
-
(Registry) Authentication Policies and Account Authentication
Policies control the maximum lifetime of tickets, both upon first issue
and upon renewal. The policy in effect for any account
(said to be its effective policy) is the most restrictive combination
of the cell policy and the policy for the account.
The RS supports the rs_policy RPC interface for operating on
property and policy information, which supports the following operations:
-
rs_properties_get_info()
Get cell property information.
-
rs_properties_set_info()
Set cell property information.
-
rs_policy_get_info()
Get cell or organisation policy information.
-
rs_policy_get_effective()
Get cell or organisation effective policy information.
-
rs_policy_set_info()
Set cell or organisation policy information.
-
rs_auth_policy_get_info()
Get cell or account authentication policy information.
-
rs_auth_policy_get_effective()
Get account's effective authentication policy.
-
rs_auth_policy_set_info()
Set cell or account authentication policy information.
PGO Items; rs_pgo RPC Interface
The Principal, Group and Organisation items in the RS datastore are
known collectively as PGO items. PGO items primarily contain:
-
A "human-friendly" (string)name, which serves as the normal
datastore query (lookup) key (not to be confused
with cryptographic keys) to PGO items (within a cell).
There are separate namespaces for Principals, for Groups and for
Organisations, and each is organised hierarchically.
(For more on naming, see
ID Map Facility
and
Integration with Naming Services
.)
-
A "computer-friendly" (because of its small fixed size and its
ability to be automatically generated) UUID which serves as the
definitive identifier of the PGO item (within the context of its
cell). ("Definitive" here means that each principal has a
unique UUID, though it may have multiple (alias) stringnames.)
The Principal domain (though not the Group or Organisation domains)
supports aliases; that is, multiple names pointing to the same
datastore entry.
The following principal names are reserved (within each cell).
- Note:
- The corresponding principal UUIDs are not reserved,
and in fact they're expected to be different in each cell-see
Privilege (Authorisation) Service (PS)
concerning DCE's "double-UUID identification scheme".
-
krb5tgt/cell-name
KDS (or surrogate) in (local or foreign) cell /.../cell-name.
Thus, for example, if the cell name of cell X is /.../cellX,
then the principal name of KDSX within the
RSX principal namespace is krb5tgt/cellX.
Similarly, for a foreign cell Y whose cell name is /.../cellY,
the principal name of KDSY within the
RSX principal namespace is krb5tgt/cellY.
-
dce-ptgt
PS in the cell.
-
dce-rgy
RS in the cell.
-
host-name/self
SCD on the specified host (host-name) in the cell.
This is also called the host principal or machine principal
of the host host-name.
The following group name is reserved (within each cell):
The following organisation name is reserved (within each cell):
The RS supports the rs_pgo RPC interface for operating on RS PGO
datastore items, which supports the following operations:
-
rs_pgo_add()
Add a PGO item.
-
rs_pgo_delete()
Delete a PGO item (also delete any account (see below) depending
on the deleted PGO item).
-
rs_pgo_rename()
Change the name of a PGO item.
-
rs_pgo_replace()
Replace the information associated with a specified PGO item.
-
rs_pgo_add_member()
Add a member principal to a group or organisation.
-
rs_pgo_delete_member()
Delete a member principal from a group or organisation.
-
rs_pgo_is_member()
Test whether a principal is a member of a group or organisation.
-
rs_pgo_get_members()
Return a list of member principals of a group or organisation.
-
rs_pgo_get()
Retrieve a PGO item (identified by any of several query key formats)
from the RS datastore.
-
rs_pgo_key_transfer()
Convert one query key format to another.
Accounts; rs_acct RPC interface
Accounts are the targets of login rituals.
Account items consist of, minimally, a triplet of a principal, a
primary group, and an organisation. The account
may also contain a list of secondary groups known as a
concurrent group set, which together with the primary group
specifies the principal's project list; that is,
all the groups to which the principal corresponding to the
account belongs. The principal and group information in an account is
typically constructed for a user (in a PAC, in a privilege-ticket) at
login time, for use by the user throughout its login session.
Accounts are named by their principal domain component name.
Thus, when a user responds to a "login prompt" with their principal name,
they are identifying their account name as well. But even though a
principal name can be associated with only one account, the
principal itself (identified within its cell by its definitive principal
UUID identifier) can belong to multiple accounts, because of the alias
feature of the Principal domain (each alias of a principal can identify a
different account).
The following accounts are reserved within each cell (expressed as a
<P, G, O> triple):
The RS supports the rs_acct RPC interface for operating on RS
account items, which supports the following operations:
-
rs_acct_add()
Add an account.
-
rs_acct_delete()
Delete an account.
-
rs_acct_get_projlist()
Return the project list for an account.
-
rs_acct_lookup()
Return data for an account.
-
rs_acct_rename()
Rename an account (associate account information to another principal
name).
-
rs_acct_replace()
Replace an account's data.
Miscellaneous; rs_misc RPC Interface
The RS supports the rs_misc RPC interface for miscellaneous
operations:
ID Map Facility
The ID Map Facility maps (global) PGO (principal, group or organisation)
names into their cell-name and cell-relative components, and to the UUIDs
corresponding to them-and vice versa. It supports the
secidmap RPC interface and the ID Map (or sec_id) API.
As has been mentioned already (at least for principals and groups, see
Privilege (Authorisation) Service (PS)
),
PGOs in the DCE security environment are definitively identified by
a double-UUID scheme; that is, by an ordered pair of
("computer-friendly") UUIDs, consisting of a
cell UUID and a per-cell PGO UUID-
pgo-ID = <cell-UUID, pgo-UUID>, or:
-
principal-ID = <cell-UUID, principal-UUID>
-
group-ID = <cell-UUID, group-UUID>
-
organization-ID = <cell-UUID, organization-UUID>
- Note:
-
Under normal circumstances, all pgo-UUIDs in all cells will
be distinct from one another.
However, the security of the services specified in DCE require this
property to hold only within cells, not necessarily across cells.
This is discussed in detail in
Privilege (Authorisation) Service (PS)
.
Additionally, PGOs can be addressed by "human-friendly"
(string)names, namely they are identified by a concatenated cell
name and a per-cell PGO name-
pgo-name = /.../cell-name/cell-relative-pgo-name
or:
-
principal-name = /.../cell-name/cell-relative-principal-name
-
group-name = /.../cell-name/cell-relative-group-name
-
organization-name =
/.../cell-name/cell-relative-organization-name
Thus, what the ID Map Facility does is give a bidirectional mapping-
pgo-name <-> pgo-ID or:
-
-
/.../cell-name/cell-relative-pgo-name
<->
<cell-UUID, pgo-UUID>
(For more information concerning naming syntax, see
Integration with Naming Services
.)
Note that the ID Map Facility depends on dynamic (or semantic)
information, because there is no static (or syntactic)
way to decompose global PGO names into their cell-name and
cell-relative name components.
For example, a PGO name such as /.../foo/bar/zot is
"syntactically ambiguous" (disregarding the fact that the actual syntactic
string foo is not supported by any currently DCE-supported global
naming service), in the sense that it is impossible to determine
syntactically whether its components are:
-
-
cell-name = foo and cell-relative-PGO-name = bar/zot
or:
-
-
cell-name = foo/bar and cell-relative-PGO-name = zot
The DCE security facilities guarantee, however, that names are not
"semantically ambiguous"; that is, that only one (at most) principal (or
group, or organisation) has the name /.../foo/bar/zot. Note,
however, that there may be a principal and a group and an
organisation all having the name /.../foo/bar/zot. (Some more
discussion of the relationship between security and naming is given in
Integration with Naming Services
.)
The RS exports the secidmap RPC interface, to support the
sec_id API. It supports the following operations:
-
rsec_id_parse_name()
Decompose (or "parse") a global PGO name into its cell-name and
cell-relative name parts, and their UUIDs.
-
rsec_id_gen_name()
Generate (or "translate") a global PGO name, and its corresponding
cell name and cell-relative name parts, from a cell UUID and
a cell-relative UUID.
-
rsec_id_parse_name_cache()
and
rsec_id_gen_name_cache()
These are the same as the above, but additionally support client-side
cache management.
The sec_id API supports the following routines:
-
sec_id_parse_name()
Decompose a global principal name into its cell-name and cell-relative
principal name, and their UUIDs.
-
sec_id_parse_group()
Decompose a global group name into its cell-name and cell-relative group
name, and their UUIDs.
-
sec_id_gen_name()
Generate (or "translate") a global principal name, and its
corresponding cell name and cell-relative name parts, from a cell
UUID and a cell-relative UUID.
-
sec_id_gen_group()
Generate (or "translate") a global group name, and its corresponding
cell name and cell-relative name parts, from a cell UUID and a
cell-relative UUID.
Key Management Facility
The Key Management Facility provides the means by which
"non-interactive" subjects (that is, ones that do not respond to an
interactive "login" prompt, such as server programs) manage their
long-term cryptographic keys (stored in the RS datastore, as well as
in local key store).
It supports the Key Management (or sec_key_mgmt) API.
Every account-interactive or non-interactive-in DCE
has an entry in its cell's RS datastore that specifies a long-term
secret key.
In the case of an interactive principal (in particular, an
end-user), this long-term key is derived from the principal's
password (see
Login Facility and Security Client Daemon (SCD)
),
and such principals need to keep their password secure by memorising
it (rather than, say, writing it down).
Similarly, a non-interactive principal (in particular, an RPC server) also
needs to be able to store and retrieve its long-term key in a secure
manner. This has both advantages and disadvantages: it is an advantage
that a non-interactive principal's long-term key need not be
memorisable-that is, need not be derived from a password
(because randomly generated keys are more secure than keys derived from
passwords, since they are drawn from a larger key space and therefore
cannot be "guessed" as easily as passwords (password-based keys));
but it is a disadvantage that a non-interactive principal
does not have a secure storage area (such as a "brain") for memorising
its long-term key. The Key Management Facility provides such a
secure key management facility for non-interactive principals.
The RS datastore holds a (single) long-term key (together with its key
version number, see below) for each account, which
is referred to as the "current" long-term key.
Since cryptographic keys become inherently less secure as more and more
data is protected with them, it is good security policy to change
long-term keys occasionally (this is analogous to interactive users
changing their passwords). When the current long-term key is
changed, however, there may continue to exist outstanding tickets
protected with previous key(s) (in fact, this is the usual case).
This necessitates a mechanism for keeping track of "usable" keys
(that is, those for which outstanding usable tickets protected with
these keys continue to exist).
That problem is solved in DCE by providing
for key version numbers and a local key store, whereby
all usable (current and previous) long-term keys are tagged with a version
number; and this information is maintained "locally" by each server
(that is, securely with respect to security policy, and in an
implementation-defined sense).
It is the sec_key_mgmt API that realises this key maintenance
facility. Implementations are required to retain keys of all
version numbers for which there may exist outstanding tickets,
unless such tickets need to be explicitly revoked because their
keys are suspected of being compromised (see
sec_key_mgmt_delete_key()
and
sec_key_mgmt_delete_key_type(),
below).
While these key management routines themselves are designed to be secure,
the ultimate security of the long-term keys they manage-in
particular the implementation-dependent local key storage of the keys
themselves-depends also upon the security of
local hardware and OS, and that involves questions of integration of
DCE security and local security beyond the scope of this specification.
Typical implementations will locally store keys in files (called
key table files) managed by the local OS (and therefore protected by
whatever means the local OS protects it files), although the Key Management
Facility accommodates other storage means as well.
Finally, the Key Management Facility provides a means to
delete keys (thereby revoking tickets protected with those keys)
-non-interactive principals use this when old keys expire, or when a
key is suspected of being compromised.
Some of the routines below take a key type as a parameter, which
identifies the cryptoalgorithm in use (for example, DES).
The Key Management (or sec_key_mgmt) API consists of the following
routines (except for those specifically noted to communicate with the RS
server, they are all "local"; that is, no protocol is specified for them,
and the implementation must guarantee their security):
Login Facility and Security Client Daemon (SCD)
The Login Facility provides the means by which subjects (RPC
clients) manage their DCE login context(s).
It supports the Login (or sec_login) API.
A ("network") login context contains the information necessary
for a subject to become a client in the DCE security environment;
that is, to invoke protected RPCs. Namely, a client "annotates" an RPC
binding handle with the security information present in a login context, via
rpc_binding_set_auth_info()
(as described in the referenced Open Group DCE 1.1 RPC Specification).
Login contexts are represented to the application programmer as an
"opaque pointer" (that is, a pointer to a data structure whose internal
structure is implementation-dependent and not further specified),
but conceptually the information held in login contexts normally
includes such items as:
-
Identity information concerning the subject's account (stored in the RS
datastore), such as principal stringname and principal/group UUIDs,
contained in a ticket and privilege-ticket issued by the KDS and PS of the
subject's cell. The protected parts of this information (including the
session keys between the subject and the KDS and PS) may be encrypted (if the
login context is unvalidated) or decrypted (if it is validated).
-
(Registry) policy information, such as the maximum lifetime of tickets.
-
State information, including the validation state of the login
context (that is, whether or not it has been "validated" (decrypted)),
and its certification state (that is, whether or not is has been
"certified" (described below)).
-
The authority for authentication information (it may originate from the
DCE TCB, or from the local TCB if the network is unavailable for
some reason).
- Note:
-
A "login context" need
not be established by an actual interactive end-user login ritual, but
may be established via the sec_login API. Furthermore, multiple
login contexts may be associated with a single "process context", and
vice versa. Another name for "login context" is
(client-side) security context.
A login context is said to be validated if the
information contained in it is trusted by the principal/account
associated with the login context (provided, as always, that the
principal/account trusts the security of its own long-term key).
Said in more intuitive terms, an unvalidated (or
prevalidated) login context is one which is still protected
(that is, partially encrypted) in the long-term key of the
principal/account with which it is associated;
a validated login context is one which has been (correctly)
decrypted (and hence can be trusted to the extent that the
key used to decrypt it is trusted).
The practical meaning of "validation" is that the login context is in
a format (namely, decrypted) that can be used for protected RPCs
(that is, to "annotate" RPC handles), and that the client trusts
it for this purpose.
A more specialised notion than that of validation is certification.
A validated login context is said to be certified if
-and to the extent that-
it is trusted by parties other than the principal/account
associated with the login context. The prototypical example of such an
"other party" is the local TCB of the client's host, especially its
"login program" (or other "entrance portal"): the local TCB typically
requires a high level of trust in a client's login context, because it
typically uses the client's network login context to establish its local
login context, issuing the client its local security credentials on the
basis of its global ("network") credentials (by means of a
host-specific "UUID-to-host-ID" mapping), thereby enabling the client
to access local OS resources (modulo local access controls).
However, an "other party" could just as well be a non-TCB party
(that is, another principal) instead.
This certification of a (validated) login context, by another party
suspicious of it, can be accomplished if the other party can use the
login context to
successfully "impersonate" the principal/account associated with the
login context (note that the other party has access to the required
identity information to attempt this, since it is present in the login
context-in particular, the client must trust the other party to
the extent that it exposes this information to it): for, if the login
context can be used to successfully execute a protected RPC to a trusted
party (say, to the local TCB itself), then the information in the login
context must have been genuine; that is, it is trustable. (There is,
however, a subtle point regarding "trusted communications" between the
other party and its local TCB-this is discussed in
Further Discussion of Certification
.)
This model requires that the local TCB is instantiated as a (server)
principal with respect to the DCE TCB-and it is
the function of the Security Client Daemon (SCD) to perform that
role: the SCD "is the DCE principal of the local machine". It has
principal name host-name/self (within its cell).
The SCD supports the scd RPC interface for the purpose of
supporting certification.
- Note:
-
There is no necessary relationship between the DCE host name,
host-name, and any other (non-DCE) name the machine may be
endowed with (for example, last component of Internet host name). By
convention, however, host-name typically has the form
hosts/short-host-name (within its cell), where
short-host-name is "the same" short name that the machine is
known by for other purposes (for example, the last component of
an Internet host name).
Of all the login contexts supported by a given process, there is (at
most) one that is distinguished among them, called the process'
current login context.
This is a process-wide notion (and not, for example, a thread-specific
notion).
A process' current login context is, by definition, the (only)
login context that is (automatically) inherited by child processes;
it is very common for a process to possess only a single login context,
and for this to be designated its current login context.
The current login context is also the process' default login
context, which is by definition the login context that is
considered to be in effect in situations where a login context is
required but none is otherwise specified (see, in particular,
rpc_binding_set_auth_info()
in the referenced Open Group DCE 1.1 RPC Specification).
Care should be taken not to confuse the (process-wide) notions of
current and default login context with the notion of the host's
login context, which is by definition the login context
associated with the host's principal/account itself ("self").
A process at its start-up time may or may not have a current login context,
depending on its parent's actions (namely, whether or not the parent
had designated a current login context and enabled or disabled
current login context inheritance).
This consideration is especially interesting in the case of a "machine
boot" scenario, where for typical implementations it is desirable for
an operating system's "initial process" (sometimes called init)
to "run as the host principal" (that is, to have its current login
context be the login context of the host principal/account),
and for that login context to be inherited by the other boot
or "daemon" processes (but not by ordinary "user" processes).
Special routines are included in the sec_login API (below) to
cater to this important special case.
An end-user command for "logging in" to the DCE environment is not
specified in this document, though implementations will typically
provide a host-specific "login program" (or "login command"),
and give it the following functionality (all relative to the user's
home cell):
-
Request the user's login name, and obtain a ticket for that user from
the KDS.
(That is, begin to set up a login context for the user; see
sec_login_setup_identity()
below.)
-
Request the user's password, map it to a cryptographic key, and verify
that it is the same as the user's long-term key protecting the ticket
(by verifying that it correctly decrypts the ticket).
(That is, validate and complete the set-up of the login context; see
sec_login_validate_identity()
below.) Then, send the ticket to the KDS, requesting a ticket to the PS;
and send this ticket to the PS to obtain a privilege-ticket for the user,
and decrypt that.
-
Map the user's "network identity information" (stored as a stringname
in the ticket, and as UUIDs in the PAC (or obtainable through the EPAC
set seal) in the privilege-ticket)
to "local host identity information", after first checking that the
information contained in the ticket and privilege-ticket is trustworthy.
(That is, certify the login context; see
sec_login_certify_identity()
below.)
(Actually, for the important special case of a (locally) privileged
process-that is, a trusted process in the host's TCB, such as
its login program-a special routine is supported,
sec_login_valid_and_cert_ident(),
which not only combines validation and certification, but is "more
infallible" than
sec_login_certify_identity()
-see
Further Discussion of Certification
.)
-
Arrange for the user's login context to be inherited by the login
process hierarchy, so that it is available for the user's entire login
session (typically, the user's "login shell" and its child processes
(recursively)). (That is, set the current context; see
sec_login_set_context()
below.)
To accomplish these activities, the login program uses (parts of)
the sec_login API, which consists of the following routines.
These routines are designed to be called both by interactive host login
programs (as described above), and by non-interactive programs that need
to act as RPC clients (under potentially multiple principal/account
identities). A few of these routines are primarily designed to be called
by specific programs, such as a host's login program, or the local
host's first (or "initial") process ("init") after a system boot.
-
sec_login_init_first()
Initialise the calling process' current login context inheritance
mechanism, thereby making the calling process' current login context
(potentially) accessible to other processes on the local host.
In typical usage, this routine is called only by the host's initial process
at boot time ("init") to initialise the host's login context
for inheritance by the host's hierarchy of daemon processes which are
spawned as child (and sub-child) processes of the initial process.
(The calling process' current login context is actually "set up" by
sec_login_setup_first(),
below.)
-
sec_login_setup_first()
Similar to
sec_login_setup_identity()
(below), except that the only login context it can set up is the
local host's (unvalidated) login context (that is, the login
context associated with the host's principal/account ("self")).
In typical usage, this routine is called only by the host's initial
process (or, if this functionality has not been integrated into the
host's initial process, by SCD).
-
sec_login_validate_first()
Similar to
sec_login_validate_identity()
(below), except that the only login context it can validate is
the local host's login context.
-
sec_login_setup_identity()
Set up a login context; that is, create an (unvalidated and
uncertified) login context for a specified principal/account (recall
that accounts are uniquely identified by their principal name
component), in the address space of the calling client. Such a login
context is protected (that is, parts of it are encrypted), and it is not
usable until it has been validated (that is, decrypted, by
sec_login_validate_identity()).
-
sec_login_validate_identity()
Validate a login context; that is, make it usable for making
protected RPCs (in the sense of making it usable by
rpc_binding_set_auth_info()),
and in the process demonstrate its trustworthiness (for use
in protected RPCs) to the principal/account to which it is associated
(assuming the security of the long-term key of the
principal/account associated with the login context).
This is typically accomplished by decrypting the encrypted part of the
login context (and verifying that the decryption is correct), using the
long-term key of the principal/account-hence, this information must
have been encrypted by an entity knowing the principal/account's
long-term key, which must have been a trusted entity (by hypothesis).
-
sec_login_certify_identity()
Certify a (validated) login context; that is, demonstrate its
trustworthiness
(for the purpose of basing access decisions on information carried in it)
to parties other than the principal/account to which it is associated.
This is typically accomplished by impersonating (as a client) the
principal/account to which the login context is associated, by
verifying that the login context can be used to execute a protected
RPC to the local host's SCD. (See
Further Discussion of Certification
.)
-
sec_login_valid_and_cert_ident()
Simultaneously validate and certify a login context
(that is, combine the functionality of
sec_login_validate_identity()
and
sec_login_certify_identity()
into a single routine), in a manner appropriate for use by
privileged processes.
This is typically accomplished by impersonating the local host's SCD,
which may be thought of as "the local TCB invoking a protected RPC to
itself", and is "infallible" (that is, completely secure, modulo the
security of the local TCB). (See
Further Discussion of Certification
.)
-
sec_login_set_context()
Set a login context; that is, register it in the sense of
making it (potentially) accessible to other processes on the
local host, and moreover make it the calling process' current
login context.
-
sec_login_get_current_context()
Retrieve the calling process' current login context.
-
sec_login_release_context()
Release a login context; that is, free the memory allocated to it
(this does not affect the accessibility of other processes to the
login context).
-
sec_login_purge_context()
Purge a login context; that is, unregister it in the sense of
making it inaccessible to the calling process and to other processes on
the local host (typically, this involves eradicating all memory and disk
storage of the login context).
-
sec_login_export_context()
Export a login context; that is, create an advertisement for it.
Such an advertisement consists of information that can
be communicated to other processes and enables them to (potentially)
share the login context (such sharing is restricted to processes on the
local host).
-
sec_login_import_context()
Import a login context; that is, create a login context
from its advertisement.
-
sec_login_newgroups()
Restrict the list of groups associated with a login context.
(This is designed for supporting "least privilege" security policies
that require clients to act with the minimal set of privileges necessary
for successful completion of their tasks.)
-
sec_login_get_groups()
Retrieve local host group membership information from a login context.
-
sec_login_get_expiration()
Retrieve the expiration date of a login context, which is the date
beyond which RPC binding handles annotated with the login context
(in the sense of
rpc_binding_set_auth_info()
in the referenced Open Group DCE 1.1 RPC Specification) will fail.
-
sec_login_refresh_identity()
Refresh a login context; that is, increase its expiration date to the
maximum allowable; the refreshed login context must be revalidated.
-
sec_login_inquire_net_info()
Retrieve certain "network information" (PAC data and expiration data)
from a login context.
-
sec_login_free_net_info()
Free memory allocated for "network information" structure.
-
sec_login_get_pwent()
Retrieve local host information associated with a login context.
In addition, support for delegation introduced into DCE in DCE 1.1
provides the additional functionality listed in the
next section.
Delegation-Related Functions
The following functions are used to establish delegation chains
and perform delegation related functions. The provide the following
functionality:
-
The ability to enable delegation.
-
Also, the ability to select the type or form of delegation desired.
This permits the following capabilities:
-
The ability of an intermediary service to impersonate the
initiator of the service. In this instance, the identity of
the (impersonator) participant in the call chain is not preserved
in a call chain of participants associated with performing the
requested service.
-
The ability of an intermediary service to act as a delegate
on behalf of the initiator of the service. In this instance,
the identity of the (delegated) participant is preserved in a
call chain of participants associated with performing the requested
service.
To accomplish this, the implementation's host-specific "login
program" (or "login command") uses (parts of) the
sec_login API consisting of the following routines. As
previously mentioned, these routines are designed to be called
by both interactive host login programs and by non-interactive
programs that need to act as RPC clients. The routines are:
-
sec_login_become_delegate()
This function is used by intermediate servers to become a
delegate for their caller.
-
sec_login_become_impersonator()
This function is used by intermediate servers to become an
impersonator for their caller.
-
sec_login_become_initiator()
This function constructs a new login context that enables the
selected delegation type. The login context is unvalidated
and uncertified. Unless this function is invoked, delegation
is not permitted on behalf of the the originator of a
request for service.
The delegation types that are permitted are impersonation
and (traced) delegation.
-
sec_login_cred_get_delegate()
This function is used to iterate through and extract the
privilege attributes of the delegates listed in a specified
login context.
-
sec_login_cred_get_initiator()
This function is used to extract the initiator's privilege
attributes from a specified login context.
-
sec_login_cred_init_cursor()
This function is used to intiialise a sec_cred_curson_t
to be used as a cursor to iterate through the list of delegates
for a service. It is used in calls to the iterative routine
sec_login_cred_get_delegate.
-
sec_login_disable_delegation()
This function returns a login context without delegation
or impersonation enabled, from one that has one of the
two delegation types enabled.
-
sec_login_purge_context_exp()
This function destroys expired network credentials
associated with a specified (AS) ticket.
-
sec_login_set_extended_attrs()
This function constructs a new login context that contains
the requested attributes.
- Note:
- Attributes cannot be added to a delegation chain in this manner.
Thus, if a login context referring to a delegation chain is passed
to this routine, an error indication an invalid context will
be returned.
-
sec_login_tkt_request_options()
This function is used by a client to request specific AS
ticket options. It is an optional function. It is designed
to be called after
sec_login_setup_identity()
or
sec_login_refresh_identity()
and before
sec_login_validate_identity()
or
sec_login_valid_and_cert_ident().
The requeste options will override the defaults when the
ticket is requested at validation time.
The SCD exports the scd RPC interface, which supports the
following operation:
Further Discussion of Certification
The notion of certification (as introduced in
Login Facility and Security Client Daemon (SCD)
)
is a subtle one, in respect both of:
-
the need for such a notion
-
the requirements it makes upon implementations.
Therefore, in order to clarify this notion, this section discusses
it in more depth, with special emphasis on these two points.
The synopsis of this section is as follows:
-
-
There exists a certain (very small) risk that a login context can
be returned by
sec_login_setup_identity()
and validated by
sec_login_validate_identity(),
yet still be counterfeit.
The scenario for this to happen is a rather arcane attack, called a
multi-prong attack (described below).
Applications that are concerned about the risk presented by this threat
must defend themselves against this multi-prong attack.
Simple validation is insufficient for this defense;
the more subtle notion of certification is required.
It is the thwarting of this multi-prong attack that is
precisely the purpose of "certification"-no more, no
less. On the other hand, applications that are unconcerned about the
risk presented by this threat of a multi-prong attack need not certify their
login contexts (and it is to support this latter set of applications that
sec_login_certify_identity()
is provided as a separate routine).
To simplify the exposition, it is convenient to begin the discussion in
this section with a definite example.
To this end, the focus will begin on the concrete case of a
host's login program (which resides in a host's
local TCB, and is privileged)-the general case of
arbitrary (not necessarily privileged) "other parties" as envisioned in
Login Facility and Security Client Daemon (SCD)
will then be a corollary of this discussion of the login program.
Consider, then, a user U attempting to log in to a host H,
claiming (a string name that identifies) a principal identity A,
and presenting a password P which maps to a long-term key
KP by means of a well-known algorithm (see
Registered Password-to-Key Mappings
).
The login program L begins by calling
sec_login_setup_identity()
to set up a login context, and
sec_login_validate_identity()
to validate it. In terms of the Kerberos authentication protocol (see
Kerberos Key Distribution (Authentication) Service (KDS)
and
AS Request/Response Processing
),
sec_login_setup_identity()
sends an AS Request message (intended to be received by the
genuine KDS (in A's home cell)) and receives an AS Response
message (intended to be received from the genuine KDS),
and the successful invocation of
sec_login_validate_identity()
convinces L that the AS Response message was correctly protected
with the key KP.
If L could somehow be certain that
KP = KA (where, as
usual, KA denotes the long-term key of A,
held in the genuine RS datastore (in A's home cell)),
then L could be confident that U "really is" A,
and that the (suspicious) ticket, TktU,KDS (let's call it),
received in the AS Response (and contained in the login context)
really is a genuine TktA,KDS naming A. This
TktA,KDS could then be used to obtain a ticket,
TktA,PS, to the genuine PS (in A's
home cell) and a privilege-ticket, PTktA,KDS containing a
trustable seal of an EPACA set ( or PACA), and L could
then with confidence retrieve this EPACA set seal (or PACA)
from the login context (using
sec_login_inquire_net_info()),
and map the information in the EPACA set seal (or PACA)
to trustable local OS credentials.
Note here that the EPAC set contains one EPAC for the initiator and
one EPAC for each delegate involved in the operation when traced
delegation is in use. In order to be sure that the privilege-ticket,
PTktA,KDS is genuine in this scenario, the seal
the PS (in A's home cell) places into PTktA,KDS
must be for the ordered list of EPAC seals in the EPAC set.
In turn, in order for L to be certain that
KP = KA, it is sufficient that
L be certain that the AS Request/Response message exchange
had actually been conducted with the genuine KDS.
However, L needs to be convinced of this-it cannot blindly
assume that the AS Request/Response message exchange had been
conducted with the genuine KDS (because the AS service is
unauthenticated).
Namely, there is a threat that L is the target of a
multi-prong attack, whereby a malicious user U collaborates with
bogus security servers (that is, malicious RPC servers that
masquerade as the genuine KDS, PS, RS and SCD servers), with the goal of
the attack being to trick L into believing that a counterfeit
login context is genuine, and thereby granting U an unauthorised
login session on the targeted host.
In such an attack, the principal A (which properly exists in
the genuine RS datastore, with its genuine long-term key
KA stored there) would have a fraudulent entry in
the bogus RS datastore, with the fraudulent long-term key
KP stored there.
If an unwary login program L were to
accept mere validation as proof of the authenticity of login contexts,
it would be vulnerable to a multi-prong attack such as this.
What is required is a way for L to certify login contexts;
that is, to defend against such a multi-prong attack.
What, then, is involved in certification? That is, what does it take to
convince L that KP = KA?
By tracing backwards along the
trust chain involved in the following sequence of tickets (where the
subscript "U" indicates that L is suspicious of these tickets
until it can be convinced of their genuineness):
-
-
TktU,KDS -> TktU,PS ->
PTktU,KDS -> PTktU,SCD
it can be deduced that: if PTktU,SCD
is correctly protected with the genuine long-term key
KSCD of the local host's SCD, and if L can be convinced
of this fact, then L is justified in believing that all these
suspicious tickets are in fact genuine, and in particular that the
long-term key protecting TktU,KDS is
KA-
that is, that KP = KA.
(All this assumes that the DCE network TCB and the local host's TCB
are uncompromised, of course.)
At this point, recall that L is part of the local host's
TCB; that is, is privileged.
Therefore, it is possible (and is not a breach of security) for L to
(legitimately) adopt the identity (as a server) of the local
host's SCD, in the sense of L's knowing and using the long-term key
KSCD (which L can retrieve by using
sec_key_mgmt_get_key()
or an implementation-specific equivalent). If L can successfully use
KSCD to directly verify that PTktU,SCD
is correctly protected with the genuine long-term key KSCD,
then the certification problem is thus solved for L.
This adoption of the SCD's identity by L can be thought of
as "the local TCB invoking a protected RPC to itself",
and it is "infallible" (in the sense of being completely secure,
modulo the security of the network and local TCBs).
And this is typically how
sec_login_valid_and_cert_ident()
is implemented (furthermore, this direct access to KSCD shows
"why"
sec_login_valid_and_cert_ident()
is a privileged routine).
While this adoption of the SCD's identity solves the certification problem
for privileged processes, it is not a solution that is available to
non-privileged processes (because it is a breach of security for
non-privileged processes to have knowledge of the local TCB's long-term key
KSCD; that is, to have KSCD in their address
spaces). This is why
sec_login_certify_identity()
is supported. The design criterion for
sec_login_certify_identity()
is that it is intended to provide the strongest guarantee of
certification that can be provided to a non-privileged process, modulo
the exigencies of a given implementation.
The strength of this guarantee is, in general,
implementation-specific-in particular,
sec_login_certify_identity()
may be "not quite as infallible" as
sec_login_valid_and_cert_ident()
(in which case, this must be specified in the implementation's
documentation of
sec_login_certify_identity()).
- Note:
- In typical implementations,
sec_login_certify_identity()
is implemented as a protected RPC intended to be handled by the local host's
SCD server, at a protection level other than rpc_c_protect_level_none
(see
Protected RPC
),
and annotated (in the sense of
rpc_binding_set_auth_info())
using the suspicious login context in question (that is, using
PTktU,SCD to authenticate the invoker of
sec_login_certify_identity()
to the SCD server). If this RPC returns successfully (that is, the SCD's
scd_protected_noop()
operation succeeds as a protected operation), then, similarly to the case of
sec_login_valid_and_cert_ident()
above, the calling application is justified in concluding that
PTktU,SCD is correctly protected with the genuine
long-term key KSCD, and the certification problem is thus
solved in the non-privileged case.
There is a caveat in this scenario, however; the implementation of
the RPC (called inside
sec_login_certify_identity())
must somehow guarantee (in a manner that does not depend on the
suspicious PTktU,SCD) that this RPC really is
handled by the local host's genuine SCD server.
To the extent that the implementation can make this guarantee,
sec_login_certify_identity()
can be trusted (that is, approaches the "infallibility" of
sec_login_valid_and_cert_ident()).
An example of criteria that implementations may support that are
sufficient to make this guarantee (and thereby make certification via
sec_login_certify_identity()
just as infallible as that via
sec_login_valid_and_cert_ident())
is the following:
-
-
The client's RPC to the SCD is:
-
done over a trusted local host-only transport (such as a "local
loop-back transport", or "UNIX-domain sockets",
or "local shared memory", and so on)
-
addressed to a trusted transport endpoint on which the SCD is listening
(for example, the SCD could have written this to a world-readable file,
protected by local host security, at its boot time, from which
sec_login_certify_identity()
could read it in a trusted fashion).
Not all platforms are able to meet the above criteria, and
even those that do may not do so in a portable manner.
Another example of implementation criteria, which are more
widely supported and portable but which, however, give
a guarantee not as "infallible" as the preceding,
are the following:
-
-
The client's RPC to the SCD is:
-
done over an untrusted transport implemented in such a way that
messages addressed to transport endpoints on the local host do
not go off-host (this property, which is quite common in
existing implementations, guarantees that the conversation key
K^^^ in criterion (3) below is not exposed to
network eavesdropping)
-
addressed to a trusted transport endpoint on which the SCD is
listening (see above)
-
the conversation key K^^^ involved in the RPC is
specified by the client and is used by the SCD (to protect
its returned error_status_ok status value).
(Note that criterion 3. is satisfied by the CL RPC protocol (see
Conversation Manager out_data
),
but not by the CO RPC protocol (see
CO Verifier auth_value.credentials
).)
(The threat of off-host bogus servers sending messages to the
client at exactly the right moments still exists, but the danger
of doing so successfully is lessened by the presence of the
client-chosen conversation key.)
If an implementation of
sec_login_certify_identity()
does not support the same strong guarantee of "infallible"
certification that
sec_login_valid_and_cert_ident()
does, this fact (as well as information about the strength of the
guarantee that actually is supported) must be noted in the
implementation's documentation of
sec_login_certify_identity().
Integration with Time Services
It is a fundamental characteristic of cryptographic algorithms and
protocols based on computational complexity (as opposed to those
based on "theoretically perfect security", such as so-called
one-time pads (for example, single-use codebooks)) that their security
depends in an essential way on time. The reason is that their
security can be undermined if the cryptanalyst has access to sufficient
computational power to overcome the barriers imposed by computational
complexity, and availability of such computational power can be
guaranteed (at least theoretically, if not practically)
if enough time is available. For example, given enough time, a
cryptanalyst can "crack" (that is, cryptanalyse) a key-based
cryptosystem by simply "exhausting the keyspace"; attempting to decrypt
encrypted messages using all possible keys until one "correctly"
decrypts the message (provided the "correct" decryption can be
recognised, for example, by recognising some "verifiable plaintext").
Further, the longer a key has been in use, the more traffic has likely
been protected with it, and therefore the more likely it will become the
target of a compromise attempt. Thus, among other considerations, the
length of time a key is valid needs to be limited.
As a countermeasure intended to thwart such attacks, the Kerberos
authentication protocols use timestamps, in several ways:
-
Tickets
Four timestamps in each ticket are used as
timeouts to bracket the validity of the ticket; that is, to delimit
the times at which the clients should present and servers should honour
the ticket (that is, use the session key in the ticket or a negotiated
conversation key, with good expectations of security). These timestamps
are generated by the KDS itself, and interpreted by the target server.
(With most current technology, a day is usually considered a relatively
safe lifetime for a DES key.)
-
Authenticators
One timestamp (broken up into two fields)
is used in each authenticator, as a freshness constraint
to counter replay attacks (see below).
This timestamp is generated by the originating client and interpreted by
the target server, to prove to the server that the client "currently"
knows the session key (where a clock skew on the order of a few
minutes is built into the interpretation of "currently", to compensate
for network or other processing delays-this clock skew is taken
into account in all other authentication protocol timestamps, too).
("Replay attack" in general refers to a wiretapper intercepting a
message and later (perhaps after disabling the initiator's system, for
example, for the purpose of using its network/transport address)
resending it to the intended target claiming to be the original sender.
In the present case, the replay attack threatens only to provide
opportunities for bogus authentications, not to expose keys
-thus only the security attribute of authenticity is at risk, not
integrity or confidentiality.)
-
Other
Timestamps are also used in various other places
in the authentication protocol (generated and interpreted by various
entities, sometimes protected and sometimes not protected), and
elsewhere (for example, as timeouts for long-term keys in the RS).
Details are discussed at appropriate places in later chapters.
Some compromises of timestamp security might be tolerated if they only
lead to denial of service, but in order to generally guarantee the
security of the authentication protocols, timestamps must be not only
protected by the protocol itself, but they must also be secure when
initiators generate them, and when receivers interpret them.
That is, all these entities must have a secure source of (accurate)
time available to them.
This secure source of time is provided in the DCE environment by the
Distributed Time Service (DTS)-which therefore needs to be
considered as a component of the DCE TCB.
(This does not preclude other sources of trusted time being
used.) In the DTS architecture,
communications among DTS entities are protected, leaving the only
exposed transmission of time information being the original importation
of time from an external source into the DCE environment. Securing
that external trust link, together with resolving the issues involved
in bootstrapping and configuration of the DCE environment (for
example, to break the potential "vicious circle" of the symbiotic
relationship of DTS depending on Security and vice versa), while
security-relevant, are administrative (not architectural) concerns, and
as such are beyond the scope of this specification.
That is, this aspect of the security environment is
implementation-dependent.
Integration with RPC Services
The programming model supported by DCE endeavours to present
security services to "main-line" RPC programmers in a way that
largely insulates them from the intricacies of the underlying security
mechanisms, and from the security APIs and RPC interfaces
specified in this specification, thereby enhancing assurances that
security-sensitive applications can be written correctly. The security
RPC APIs (specified in the referenced Open Group DCE 1.1 RPC Specification) relevant to this
purpose are the following:
- Notes:
-
Prior to DCE 1.1, servers would call
rpc_binding_inq_auth_client()
to obtain a handle to a client's credentials (rpc_authz_handle_t).
This handle was not opaque and was dereferenced with a cast to
the data type sec_id_pact_t *.
Because that datatype lacks abstraction, it cannot be used to obtain
DCE 1.1 (or beyond) credentials, which may be a chain of EPACs. Instead,
rpc_binding_inq_auth_caller()
has been added for use by all servers for DCE 1.1 and newer versions.
It replaces the
rpc_binding_inq_auth_client()
which is still available for use with existing (pre-DCE 1.1)
application servers.
-
The security-relevant parameters to these
interfaces relating to authentication, protection and authorisation
services, rpc_c_authn_dce_secret and rpc_c_authz_dce, are
introduced elsewhere in this chapter.
-
rpc_server_register_auth_info()
Set server's security information, by registering it with the RPC
runtime.
-
rpc_binding_set_auth_info()
Set client's security information, by "annotating" an RPC binding
handle to a server.
-
rpc_binding_inq_auth_caller()
Server retrieval of an authenticated client's security information from
a binding handle.
-
rpc_binding_inq_auth_client()
Server retrieval of client's security information from a binding handle.
- Note:
- This call is provided for compatibility with pre_DCE 1.1 applications
only. It should not be used for DCE 1.1 and newer version applications.
-
rpc_binding_inq_auth_info()
Client retrieval of server's security information from a binding handle.
-
rpc_mgmt_inq_server_princ_name()
Return server's principal name to client.
-
rpc_mgmt_set_authorization_fcn()
Establish server's authorisation function, for its RPC management
routines.
Finally, it is to be noted that security metadata (such as tickets and
authenticators), apart from its implicit appearance within protected RPC
protocols (and therefore invisible from the point of view of the
programming model), appears as explicit application-level data in the
krb5rpc and rpriv RPC interfaces. Due to the specification
of the transfer syntax of this data (in ASN.1/BER, not IDL/NDR), these
RPC interfaces are specified in terms of the IDL byte data type
(so-called "opaque RPC transport", not making use of the marshalling
features of IDL). These RPC interfaces are invoked at protection level
rpc_c_protect_level_none (because the data they carry is already
protected by direct cryptographic means, not via "protected RPC").
- Note:
-
Some implementations may wish to offer KDS services over "raw" UDP
(port 88) in order to be compatible with other implementations of the
Kerberos protocols, but that is an implementation choice and this
document makes no specifications along those lines.
Integration with Naming Services
As discussed in
Registration Service (RS) and RS Editors
,
the RS in every cell maintains a (RS) Policy item and three datastore
"domains" of PGO items. For datastore query/lookup purposes,
the RS addresses these items by names managed by the RS server
itself, called RS-names or security-relative names
(the relationship of RS-names to other kinds of names is
specified in this section). The RS-names of the Policy item
and of the PGO items have the forms:
-
policy
(RS) Policy item.
-
principal/P-name
Principal items.
-
group/G-name
Group items.
-
org/O-name
Organisation items.
P-names, G-names and O-names are collectively known as
PGO-names. (For reserved PGO-names, see
PGO Items; rs_pgo RPC Interface
.
See also
The rs_pgo RPC Interface
,
where the three PGO "domains" are identified by explicit parameters
instead of by initial namestring components-a naming technique
equivalent to the namestring syntax discussed here, but more convenient for
"computer-oriented" use, as opposed to "human-oriented" use.)
Now, the RS protects its (Policy and PGO) items with ACLs, hence in
accordance with
ACL Editors
,
these protected items must be named.
In order to name these protected RS items,
DCE specifies that the RS in every cell must be registered,
not only as an RPC service in CDS as a simple RPC server entry (via its
rs_bind interface), but also as an RPC server group entry,
called the security junction RPC group, referred to as
"sec-junction" (concerning the notion of junctions, see
ACL Editors
).
Within each cell, the actual
name of sec-junction is not itself directly specified, but it is
indirectly identified in the /.:/cell-profile RPC profile entry
(which is a well-known name) as having the name associated with
a certain UUID (namely, that of the rs_bind interface).
(Conventionally, sec-junction is usually simply called
sec.) For more information on this topic, see
RPC Binding Models
.
That is, the (RS) Policy and PGO items held in the RS in each cell
are identified, for the purposes of ACL editing
("as for protected objects in the RS datastore itself"), by names
appropriate to the sec_acl API interface, and these have the form:
-
/.../cell-name/sec-junction/policy
-
/.../cell-name/sec-junction/principal/P-name
-
/.../cell-name/sec-junction/group/G-name
-
/.../cell-name/sec-junction/org/O-name
Note that these names, because they include the /sec-junction/domain
substrings (where domain varies over
principal, group and org), are slightly different from
the global principal and group names appropriate to the ID Map Facility.
(Note the ID Map Facility has no notion of the Policy item at all; and
while the secidmap RPC interface supports "organisation names", the
sec_id API doesn't.) Namely, global principal (resp., group) names
consist only of the cell-name and the cell-relative principal (resp., group)
name, where the latter is defined to be "the same as" the corresponding
RS datastore item's P-name (resp., G-name)-the
sec-junction/domain substring is not included. Thus,
principals (resp., groups) have "the same" global names as their
corresponding RS datastore items, except that the substring
sec-junction/principal/ (resp.,
sec-junction/group/) is omitted.
Thus, for example, the "partially qualified" terminal string
foo/bar/zot taken out of context is ambiguous, because it can name
several different things depending on its context, as follows:
-
"The principal foo/bar/zot in a cell" (in a context where a
principal name is appropriate) has the fully qualified name
(in the sense of the ID Map Facility):
-
-
/.../cell-name/foo/bar/zot
-
"The RS datastore item in a cell holding information for principal
foo/bar/zot" (that is, having this P-name)
has the fully qualified name (in an ACL management context):
-
-
/.../cell-name/sec-junction/principal/foo/bar/zot
-
"The group foo/bar/zot in a cell" (in a context where a group
name is appropriate) has the fully qualified name (in the sense of the ID
Map Facility):
-
-
/.../cell-name/foo/bar/zot
-
"The RS datastore item in a cell holding information for group
foo/bar/zot" (that is, having this G-name)
has the fully qualified name (in an ACL management context):
-
-
/.../cell-name/sec-junction/group/foo/bar/zot
-
"The RS datastore item in a cell holding information for organisation
foo/bar/zot" (that is, having this O-name)
has the fully qualified name (in an ACL management context):
-
-
/.../cell-name/sec-junction/org/foo/bar/zot
A final question arises about the relationship between client and server
principal names and their CDS-registered service names (holding binding
information) as RPC applications.
That there is no necessary relationship is easily seen from the
fact that both clients and servers must have principal names to
participate in the DCE security environment, yet for RPC binding
purposes only servers (not clients) need be registered with CDS (and in
fact, even servers need not be registered if "string bindings" are used).
Similarly, there is no necessary relationship between the
principal name of an RPC server and its CDS service name.
The simplest convention is for servers to have "the same" name
in both roles, for example:
-
"The principal foo/bar/zot in a cell" (in a context where a
principal name is appropriate):
-
-
/.../cell-name/foo/bar/zot
-
"The service foo/bar/zot in a cell" (that is, the CDS entry where
its RPC binding information is kept):
-
-
/.../cell-name/foo/bar/zot
However, this is merely a convention, and is not required by DCE.
All that is really required is that the means by which the
principal name of a server (or any other subject) is obtained must be
secure. It is best to consider the principal name to be part
of the service's very definition (or "service contract")-
just as much a part of its definition as, say, its service (binding) name
or its RPC interface UUID-and that an incorrect specification
of any part of the service's definition will lead to incorrect results.
RPC Binding Models
This section gives more detailed information on the RPC binding models
supported by DCE; that is, the manner in which RPC clients
use the CDS directory services to locate and establish an RPC
communications context with the RPC servers supported by DCE
-both "TCB servers" (servers belonging to the DCE TCB,
namely, RS, KDS, PS, and local hosts' SCD's),
as well as "ACL servers" (RPC servers, possibly, but not
necessarily, belonging to the TCB, that support protected objects
(via ACLs), by exporting the rdacl RPC interface).
This section requires familiarity with the referenced Open Group DCE 1.1 RPC Specification and referenced Open Group DCE 1.1 Directory Services Specification,
and it has a closer affinity with those specification than
it does with the security-specific material of the present specification.
Binding to TCB Servers
By specification, in every cell there exists in the cell's CDS
namespace, a well-known CDS node known as /.:/cell-profile, which
is an RPC profile node. Also in every cell, there exists by specification in
the cell's CDS namespace a CDS node known as /.:/sec-junction,
which is an RPC group node; the actual name of /.:/sec-junction
is not "well-known" (it can vary per cell), but by convention it
is named "/.:/sec", and it will be
denoted as such in the remainder of this section. (As will be seen,
it would even be technically possible to split the name sec into
multiple different names, say sec1, sec2, and so on,
according to its usage by different servers, say RS, KDS, and so on
-however, that would lead to unnecessary complication, and it
is not supported by this specification.)
By administrative action at cell-creation time, the following 3
interface specifications (interface UUID and version number) are
added as elements to the
/.:/cell-profile node, all of them
pointing to the /.:/sec group node:
-
The interface UUID and version number of the rs_bind interface, as
specified in
Interface UUID and Version Number for rs_bind
.
This interface specification is to be used
by clients when they bind to the RS server.
-
The interface UUID and version number of the krb5rpc interface, as
specified in
The krb5rpc RPC Interface
.
This interface specification is to be used
by clients when they bind to the KDS server.
-
The interface UUID and version number of the rpriv interface, as
specified in
The rpriv RPC Interface
.
This interface specification is to be used
by clients when they bind to the PS server.
During their initialisations, the RS, KDS and PS servers in a cell create
CDS RPC server nodes for themselves (the names of these are unspecified in
DCE, though in typical implementations the RS, KDS and PS
servers all reside in a single RPC server, and they have names like
/.:/subsys/dce/sec/master for the master instance and
/.:/subsys/dce/sec/rep_n for replicas),
in which they register their (per-cell) RPC object UUIDs (all
replicas share this UUID), their interface handles (in the notation of
the "rpc data types" reference page of the referenced Open Group DCE 1.1 RPC Specification,
these interface handles are rs_bind_v2_0_s_ifspec,
krb5rpc_v1_0_s_ifspec and rpriv_v1_0_s_ifspec, respectively),
and their RPC binding information. Then, they add themselves to the
/.:/sec CDS RPC group node, using the CDS RPC name of the server
node they just created and registered themselves in.
To bind to security services (RS, KDS or PS), a client uses the
rpc_ns_binding_import_*()
routines to query the
/.:/cell-profile node, using the appropriate interface handle
(rs_bind_v2_0_c_ifspec, krb5rpc_v1_0_c_ifspec or
rpriv_v1_0_c_ifspec, respectively), and a null object UUID.
Concerning local hosts' SCDs, see
Further Discussion of Certification
.
As discussed there, in order to support a secure
sec_login_certify_identity(),
the SCD's RPC binding information (as well as the transport underlying the
RPC) must be part of the local host's TCB.
Binding to ACL Servers
The model ("junctions") that clients use for binding to ACL servers
(servers exporting the rdacl RPC interface) has already been
discussed in the context of ACL Editors (clients of the rdacl
interface), in
ACL Editors
.
That discussion is best treated in the context of ACL Editors,
and need not be repeated here.
In the particular case where the ACL server in question is the RS itself,
the ACL binding model of
ACL Editors
together with the RS binding model of
Binding to TCB Servers
,
leads to the naming conventions (of the form
/.../cell-name/sec/principal/P-name, and so on) mentioned in
Integration with Naming Services
.
(Note that it would be technically
possible to use a junction name that is different from the
group name /.:/sec (say)-however, that would lead to
unnecessary complication, and it is not supported by this specification.)
DCE Delegation Model
In a simple distributed environment, the DCE 1.0 facilities
were sufficient to permit secure operations between two principals,
typically described as a client and a server-the initiator
and the target of the operation. In this simple environment,
the target of the operation can reasonably make authorisation
decisions based upon the identity of the initiator.
This model, while adequate for simple client/server distributed
computing, does not address the requirements of more complex
environments, for example, those based upon distributed objects,
where the target (server) needs to perform operations on other
components on behalf of the initiator. These operations on
other components must be invoked in a secure manner by intermediaries
that may not be known to the initiating principal (cleint).
The distributed environment has the characteristic that intermediate
objects, which are used to hide the details of complex system
operations, pervient the target (service - as distinguished from
object) from securely determining the identity of the initiator
of the operation on the object. All requests arriving at the
target service appear to be the result or action of the intermediary
rather than the true initiator of the operation.
The inability to determine the true initiator of a request presents
distributed systems with unsatisfactory choices, such as:
-
Implementing the service as a local one running with the
identity of the initiator.
In this instance, the service loses the benefits of distribution.
-
Running as a privileged principal that has full access to all
services it abstracts (via distributed objects).
In this instance, the service may retain distribution, but then
it would be required to implement an access control function for
each of the services (represented by distributed objects).
-
Requiring use of an alternate set of target service interfaces
that permit the authorised principal to specify the principal
on whose behalf the operation is (really) being performed.
This solution comes at the expense of redundant interfaces that
expose the details of privilege attributes to the application
protocol (thus providing opportunities for malicious attacks).
-
Implementing the service in a manner that impersonates the
(true) initiator, but where the initiator transmits its credentials
(tickets and keys) to the intermediary (impersonator) so as to
permit the intermediary to be indistinguishable from the initiator.
Unfortunately, this approach, while distributed (and in DCE, having
a high degree of location transparency), exposes the client to a
very great risk of attack-for instance, being compromised
by a Trojan horse.
The solution to this problem involves the concept of delegation.
Delegation permits an intermediary to operate upon other (non-target)
objects on behalf of the initiator in a manner that both reflects
the initiator of the operation and is distinguishable from the (true)
initiator of the request. In its simplest form, delegation
permits a subject (as described in
Subjects and Objects, Privilege and Authorisation
,
which herein is called principal A to invoke an oepration upon
(an object associated with) principal C through (an object
associated with) principal B (herein called an intermediary)
in such a manner that reflects the true initiator of the operation
(A) but which can also be distinguished from the same operation
invoked directly by A (or B, for that matter,) on C.
Overview of Delegation Model
The DCE 1.1 delegation model being described here consists of three
components:
-
An intermediary is permitted to operate upon objects in a manner
that reflects the initiator's identity as well as its own.
A target (server) receiving such a chained request would see the
privilege attributes of each participant in the chain (without
their being exposed to the application).
-
The authorisation model is extended so as to permit the target
(server or servers) to make use of the distinction between initiators
and intermediaries.
Thus, owners of a rewource may grant rights to principals acting
as intermediaries on behalf of authorised initiators without
granting rights for these principals to act (upon the objects
representing these or other services) on their own behalf.
-
Clients (initiators) performing operations (on objects) are
permitted to place restrictions upon the use of their identity
in a chain of requests for services (upon abstract objects
representing the totality of the services necessary to perform
the original client reqest) upon a target (service).
A client may choose to entirely disallow delegation or to limit
which principals (intermediaries) may use the client's identity
in a delegated manner.
-
Additionally, the nature of a caller's identity (whether
initiator, intermediary or target) is extended to include
arbitrary (in the sense of being optional) attributes
stored in the registry services (RS) of the user.
These attributes require extensions to the PAC, and may be used
by applications when making authorisation decisions.
Constrained (delegate) restrictions and also restrictions upon
the target may be imposed by the client, and also by intermediaries,
with these attributes.
In essence, the DCE 1.1 Delegation Model consists of extensions
to the following DCE 1.0 items:
It also consists of a new set of user interfaces to support
this delegation model. These are primarily in support of the
new ACLE's which also require a set of new library interfaces
as well. All this will be discussed in greater detail in the
following sections.
Components of Delegation Model
This section discusses the major components of the DCE 1.1
Delegation Model introduced in the preceeding section, in
greater detail.
Extensions to the sec_login interface (listed in
Login Facility and Security Client Daemon (SCD)
)
provide the ability for a client to enable and disable
delegation and also provide a function for servers to
become delegates. A new interface, sec_cred, is
provided as an abstraction of a set of accessor functions
for access to privilege attributes.
In addition, the PAC has been extended to encompass the
privilege attributes neccessary to accomplish delegation,
and the DCE access control mechanism has been amended to
check access of the composed principals (intermediaries)
involved, as well.
Part of the delegation extensions to the PAC include
delegation controls as well as delegate and target restrictions.
Additional application-specified required and optional
restrictions may be present.
Finally, a new set of remote interfaces is provided to aid in
authentication and authorisation. These interfaces are invoked
(indirectly) in support of delegation, and are not intended for
direct use by the application.
The Extended PAC (EPAC)
The trust mechanisms for authentication employed in DCE 1.0 by
the Privilege Server when constructing a PAC are built upon
for delegation by nesting delegated privilege attributes
in an extended PAC (EPAC).
The extended PAC contains the identity and group membership
information present in a DCE 1.0 format PAC. For compatibility
with DCE 1.0.x, a PAC may be imbedded in the authorisation
data (A_D) field of (the version 5, which is used in DCE 1.1)
Kerberos tickets. This will be shown in
EPAC Seal (and Optional Version 1.0 PAC) within A_D Field of PTGT
and is dependent
upon whether compatibility is required by the DCE application.
In addition to the information contained in the PAC, the EPAC
contains the following:
-
optional delegation controls
These controls provide a mechanism for specifying the
form of delegation-permitting one to select between
simple delegation and traced delegation (simple delegation
is also known as impersonation). These concepts are explained
elsewhere in this document.
In addition, DCE 1.1 delegation provides the ability for an
initiator or intermediary to impose restrictions on the
identities of delegates in a chain and the set of targets
to which an identity can be presented.
-
optional and required restrictions
These are provided as classes of extended registry attributes
for use by applications that have specific authorisation
requirements. They may be set by initiators and intermediaries.
-
extended attributes
These include the privilege attributes of the initiator (of the
chain of operations) as well as the privilege attributes for
each intermediary involved in the chain. Thus, the notion of
identity is extended to include chained identities. Adding
extended attributes to the EPAC permits DCE to use existing
legacy authorisation models.
Note that by including attributes within an EPAC, the attributes
may be transmitted securely (and automatically) along with a
principal's identity information. This content change also
requires a change in the manner in which extended PACs are
handled in DCE.
EPAC Seal within EPAC and A_D Field of PTGT
shows both an EPAC, and part of the Authorisation
Data field of a PTGT. Note that since the extensions in an EPAC
(as compared to a PAC) can contain an arbitrary amount of
application-selected data (which may be limited by the practicalities
imposed by RPC authorisation information size restrictions). For
this reason (and also other reasons, such as performance) EPACs
will not be placed in PTGTs. Instead, the authorisation data field
will contain a seal (cryptographic checksum) of the EPAC.
The A_D field may optionally contain a DCE 1.0 format PAC
(as shown in
EPAC Seal (and Optional Version 1.0 PAC) within A_D Field of PTGT
)
if compatibility with DCE 1.0 is required.
When delegation is enabled, the initiator may specify
this parameter.
- Note:
- The cryptographic checksum (seal of the EPAC) is performed by
the Privilege Server, PSZ, and placed within the EPAC. This
provides the same integrity guarantees previously provided for
DCE 1.0 PACs, where the entire PAC was included in the A_D field,
which is encrypted by the privilege server.
The following figure depicts the seal of the EPAC.
Figure: EPAC Seal within EPAC and A_D Field of PTGT
The following figure shows the optional Version 1.0 PAC within the PTGT.
Figure: EPAC Seal (and Optional Version 1.0 PAC) within A_D Field of PTGT
Information on the EPAC seal can be found in
Privilege (Authorisation) Services
,
in the section "Data Types". In particular, see
Extended PAC (EPAC) Interface
and
EPAC Seal
.
Linking EPAC Sets to Tickets
When traced delegation is (enabled and) in use, there may be
a set of EPACs to transmit. This set of EPACs contains one
EPAC for the initiator and one EPAC for each delegate involved
in an operation. In this case, a single seal in the PTGT is
no longer sufficient to guarantee the validity of an EPAC.
The individual integrity of each EPAC as well as the specific
order of the EPACs must be guaranteed. To obtain this integrity,
the A_D portion of a PTGT carries the seal of the ordered
list of EPAC seals.
Transmitting and Receiving EPACs
EPACs are transmitted during the authentication phase of a request.
During this phase, A PTGT is sent from the client to the server.
In DCE 1.0, the Authorization Data field of the PTGT contained a
Version 1.0 PAC. As of DCE 1.1, the Authorization Data field of
the PTGT contains the seal of the EPAC, rather than the EPAC,
for performance reasons (since it can contain arbitrary amounts of
data). So, for DCE 1.1, the KRB_AP_REQ that is passed
between the client and server will have the EPAC (or EPAC chain)
appended directly to the Kerberos KRB_AP_REQ, whereas for DCE 1.0,
the KRB_AP_REQ did not have this appendage.
To summarize, for DCE 1.0, the security message that passes between
the client and server consisted solely of a KRB_AP_REQ, which contained
a PAC.
As of DCE 1.1, the security message consists of a KRB_AP_REQ which
contains a seal of an EPAC, followed by an EPAC chain.
This is shown by the following figure:
Figure: Transmitting EPACs with Service Tickets
Extended Privilege Attribute Facility
The Extended Privilege Attribute Facility permits clients and
servers to invoke secure operations by way of one or more intermediate
servers.
Prior to DCE 1.1, simple client/server operations involved two
principals:
However, in distributed object oriented environments, frequently
server principals need to perform operations on behalf of a
client principal. In these instances, authorisation decisions
based simply on the identity of the initiator, since the
initiator of the operation may not be tie principal that requests
the operation. This is particularly true in the case of delegation.
To handle these situations, the Extended Privilege Attribute
Facility allows principals to operate on objects on behalf
of (as delegates of) an initiating principal. The collection
of the delegation initiator and the intermediaries is referred
to as a delegation chain. Using this facility (including
related sec_login calls), an application may be written
that allows client principal A to invoke an operation
on server principal C by way of server principal B.
The Authorisation Service (AS) will know the true initiator
of the operation (principal A) and can distinguish
the delegated operation from the same operation invoked
directly by principal A.
The Extended Privilege Attribute Facility consists of:
-
Login functions of the form sec_login that are
used to establish delegation chains and other related
delegation functions, listed in
Delegation-Related Functions
.
-
Security credential functions of the form sec_cred
listed in the next section.
The sec_cred and Login sec_login_cred functions
extract privilege attribute information associated with
an opaque handle to an authenticated identity. The sec-cred
functions are used by servers that have been called by a client
with atuenticate credentials. They provide servers with the
ability to retrieve information from the caller's EPAC,
since the EPAC is not available to the application as PACs
were prior in DCE 1.0. The sec_login_cred functions
are used by clients that are part of a delegation chain,
and also provide the ability to return the privilege attributes
of delegates in or initiators of, a delegation chain.
EPAC Accessor Function API
The EPAC Accessor Functions consist of an API for retrieval
of Privilege Attribute information from Extended PACs.
(They all start with the identifier, sec_cred.)
This API is provided as an abstraction of the contents of
an EPAC. It insulates applications from the format of a
PAC or EPAC, thereby relieving the necessity of dealing
directly with PAC or EPAC formats.
There are 18 functions which comprise this interface. Their
names and brief descriptions of their functions follow. See
The sec_cred API for Abstracting EPAC Contents
for further information:
RPC Authorisation Extension
Due to the need for abstraction in handling DCE 1.1 credentials
(the preceeding section listed the functions available for
this purpose), a new function,
rpc_binding_inq_auth_caller()
has been added for DCE 1.1. It replaces the
rpc_binding_inq_auth_client()
which is still available for use with existing (pre-DCE 1.1)
application servers.
This is also discussed in
Integration with RPC Services
,
"Integration with RPC Services".
This new function is used in conjunction with the
sec_cred_*()
functions-in particular, for obtaining the
client's credentials.
Enabling and Disabling Delegation
A set of extensions to the
sec_login_*()
functions provides the ability to enable delegation and
also to select the type of delegation desired. They also
provide the capability for servers to become intermediaries
in support of an operation.
These functions
are listed in
Login Facility and Security Client Daemon (SCD)
and described in
Login API
,
"Login API".
In addition, the extensions to
sec_login_*()
provide facilities for controlling the
use of delelgation, such as the ability to restrict the
allowable set of delegate and target principals. These
facilities are described in the next section,
Delegation Controls
.
The
sec_login_disable_delegation()
function disables delegation for a specified login context.
Use of this function for that context prevents any further
delegation.
Delegation Controls
The DCE 1.0 model of privelege attributes permits the data
in a PAC to be extended. With the extensions to the PAC,
the following mechanisms for controlling the form of delegation
are provided. They permit an application to implement its
own variety of models and policy for delegation.
- Note:
- Delegation only occurs if a client has chosen to enable the
projection of its identity to another entity in the distributed
system in a manner that permits that entity to operate on
behalf of the initiator.
A client process may enable delegation by annoting a login
context with the allowable set of delegates and target
principals. Once so annotated, operations using the context
will transmit the appropriate data to the server servicing
the operation. In addition, a client desiring to delegate
access (to an object) obtains a delegation token from the
Privilege Server. The delegation token is "signed" by
the Privilege Server, PSZ, to guarantee that the
privilege attributes are not modified by either the
client or the server involved in the delegation. The
client identifies the desired delegates and the eventual
targets of the delegation when making the call to the
Privilege Server. The Privilege Server, in turn, seals that
information along with the privilege attributes of the
client, which are transmitted in the request (from the
PAC or EPAC), into the delegation token.
Delegation Tokens are discussed in greater detail in
Delegation Tokens
.
The data type is described in
Delegation Token (Version 0) Format
.
The following summarizes the delegation controls provided in
DCE 1.1.
-
Impersonation or Delegation
The application can control the form of delegation by selecting
between simple (called impersonation) or traced delegation.
This form is enabled by the client application calling
sec_login_become_initiator()
with the delegation_type_permitted argument specifying
either delegation or impersonation. (See
Supported Delegation Types
for specific encodings.)
In addition, the form of delegation can be selected by an
intermediary when calling either
sec_login_become_delegate()
or
sec_login_become_impersonator().
While two forms (delegation or impersonation)
of delegation may be specified, an intermediary is not permitted
to use a form of delegation that was not enabled by the initiator.
Impersonation permits an intermediate service to "impersonate"
the initiator-where the initiator transmits to the intermediary
service the credentials (tickets and keys) necessary to be
indistinguishable from the initiator. It is often useful for
implementing remote system login utilities, for instance, and while
this increases the risk to the client of being compromised, by
a Trojan horse application, its usefulness precludes its not being
provided.
If an intermediate service attempts to select a delegation type
that is not enabled by the client, an error will be returned.
(Appendix B lists the errors that may be returned in DCE 1.1).
-
Delegate and Target Restrictions
Delegate and Target Restrictions are placed by the client and
enforced by the Privilege Server (for Delegate Restrictions)
when producing delegation credentials,
or by the Authentication Services (for Target Restrictions)
when determining if the target server is permitted to see
the client's identity.
The data types for Delegate and Target Restrictions are
specified in
Entry Types for Delegate and Target Restrictions
.
They are specified by initiators and intermediaries as an
argument to one of the functions
sec_login_become_initiator(),
sec_login_become_delegate()
or
sec_login_become_impersonator().
-
Required and Optional Restrictions
Required restrictions are added to (inserted into) the EPAC
by the Privilege Server to restrict the activities that a
server can perform. An example can be time-of-day restrictions,
or interface selections, or target object restrictions.
They are enforced by the Authentication Services for the
target server. Required restrictions must be understood
by the receiving application server; otherwise they must
deny access.
Optional restrictions are processed like required restrictions
except that applications that are unable to decode a given
optional restriction are free to ignore them. Thus, their effect
may also be limited to a given (sub)set of applications.
The data type defining Optional and Required restrictions is
found in
Optional and Required Restrictions
.
Required and Optional Restrictions are specified by initiators
and intermediaries as an argument to one of the functions
sec_login_become_initiator(),
sec_login_become_delegate()
or
sec_login_become_impersonator().
Anonymous Identity
When one of the Delegate Restrictions or Target Restrictions
placed by a client prevents an identity from being delegated
by an intermediary or seen by a target server, that identity
will be protected by being replaced in the delegation chain
by an identity containing well known anonymous privilege
attributes-in other words, by an EPAC containing id's
belonging to a well known anonymous principal and group.
The data type representing the Anonymous Identity can be found in
Anonymous Identity
.
- Notes:
-
All implementations must implement these id's as specified in
the just referenced section to ensure interoperability.
-
Currently (in DCE 1.1 and newer versions) the Authorisation
Service only has access to the server's principal name. It
does not have access to any other privilege attributes.
Thus, Target Restrictions are limited in that if ANY
are specified in a given EPAC, all target servers will
only see the Anonymous Identity (consisting of the Anonymous
Group UUID and the Anonymous Principal UUID) for that EPAC.
-
For Delegate Restrictions, if the intermediary does not satisfy
the restrictions set by a particular identity, the Privilege
Server will replace that identity's EPAC with one indicating
that an anonymous participant (Anonymous Identity - consisting
of the Anonymous Group UUID and the Anonymous Principal UUID)
was involved.
Delegation Tokens
A client that desires to delegate access to a server obtains
a delegation token from the Privilege Server, PSZ, which
is "signed" by the PS to quarantee that privilege attributes
are not modified by either the client or any server involved
in the delegation.
When a new PTGT is generated as a result of calling either
ps_request_ptgt(),
ps_request_become_delegate()
or
ps_request_become_impersonator()
(described in
Privilege (Authorisation) Services
),
the Privilege Server inserts a deletation token into the
Authorisation Data field of the PTGT.
(These functions are described in
Privilege (Authorisation) Services
.
This delegation token will be passed along with the
Authorisation Data, in any authenticated RPC calls made
using the new login context. Servers receiving those calls
will need to use the delegation token in a
ps_request_*()
to become a delegate or impersonator. Upon receiving such
a request, the PS will verify that the delegation token
matches the delegation chain (or single identity passed in)
to ensure that the proper steps were taken to enable delegation
and that none of the data has been tampered with (since that
time).
The delegation token is an MD5 checksum over the EPAC,
encrypted in the key of the Privilege Server-the seal
being of the type sec_id_seal_type_md5_des.
Only the PS can generate such a seal (it's signature),
so any tampering of the data sealed by a delegation token
would break that seal, and the Privilege Server would then
reject any requests to use that data.
- Note:
- The delegation token is passed in the Authorization Data field
along with the standard seal over the EPAC, which has not
been previously encrypted. The seal of the EPAC is used to
verify the integrity of the EPAC data for authenticated RPC
calls.
Remote Interfaces
A set of new interfaces, described in
The rpriv RPC Interface
is also provided to aid in authorisation.
They permit a PTGT to be obtained from the Privilege Server,
PSZ, by intermediary callers after having the appropriate
verifications made (depending upon the circumstances).
The data types associated with these functions are also
described in
Privilege (Authorisation) Services
,
in the subsections under "Data Types".
Extensions to ACLs
DCE 1.0 access control lists contain entries that identify the access
rights to be granted to principals bearing certain privilege attributes.
As of DCE 1.1, clients and servers are able to invoke secure
operations through one or more intermediaries.
When delegation is activated, a target server will receive an
extended PAC that contains the privilege attributes for the
initiator of the chain of operations as well as the privilege
attributes for each intermediary involved in the chain.
The Common Access
Determination Algorithm has been modified to verify that the
privilege attributes for each principal involved in the operation,
as specified in the EPAC, have been granted the necessary rights
to perform the operation.
More specifically, the standard ACL entries are extended with a
set of entries that only apply to principals acting as intermediaries.
These extended entries are called delegate entries and
permit intermediaries to be listed on the ACL without granting
those intermediaries the ability to operate on the target object
directly.
The new delegate ACL entry types used to provide access
to an identity acting as an intermediary only are:
- user_obj_deleg
- Identity that owns object
- user_deleg
- Specific principal, identified by cell-relative principal name
- for_user_deleg
- Specific principal, identified by global principal name
- group_obj_deleg
- Identity of group that is listed as owner of object
- group_deleg
- Specific group, identified by cell-relative group name
- for_group_deleg
- Specific group, identified by global group name
- other_obj_deleg
- Any principal in the local cell
- for_other_deleg
- Any principal in the specified cell
- any_other_deleg
- Any principal in any cell
For specific information on these types, the sec_acl_entry_type_t
data type describing the delegate ACLEs can be found in
ACLE Types
.
The extended authorisation algorithm is as follows:
(I) Check Initiator:
Apply standard algorithm
IF access mode is denied THEN
Deny Access & Terminate Algorithm
ENDIF
(II) Check Each Intermediary:
FOR EACH Extended PAC DO
Apply standard algorithm (allow delegate entries)
IF access mode is denied THEN
Deny Access & Terminate Algorithm
ENDIF
END
(III) Grant Access
Figure: Extended Delegation Access Control Algorithm
The preceeding figure presents a very high-level overview of the
algorithm.
Access Control Lists (ACLs)
and
The Common Access Determination Algorithm for Delegation
provide additional information on the extensions to the ACLEs
and the authorisation steps. The details of the extended delegation
access control algorithm can be found in
ACL Managers
,
in
Common Access Determination Algorithm
.
User Interfaces
The user interfaces to support this delegation model
are limited to a new set of DCE ACL entry types that are
in addition to the ones existing for DCE 1.0. The addition
of these types does not cause any change in behavior
for existing ACL Editors (unless they explicitely need
to use one or more of the new entry types to provide
authorisation control for delegation purposes). For the
new entries, the key and permission types are defined
exactly as they would for other existing DCE ACLEs.
(As noted in the previous section, the new extensions to the
ACL entry types can be seen in
Access Control Lists (ACLs)
.
The authorisation steps can be seen in
The Common Access Determination Algorithm for Delegation
which lists the steps for both existing (legacy) ACL
management, and also those for delegation.)
No wire protocol changes are necessary to support these
new ACL entry types, since they are simply additional
values of the existing sec_acl_entry_type_t
data type, which can be seen in
ACLE Types
.
Extended Registry Attribute Facility
The DCE 1.0 user registry facility uses a static schema.
The Extended Registry Attribute Facility is an
attribute facility that employs a dynamic schema.
The Registry (for DCE 1.0) is a repository for principal,
group, organization and account data. It stores the
network privilege attributes used by the DCE as well
as account data used by local operating systems.
The local account atributes are appropriate only for
UNIX operating systems.
The Extended Registry Attribute (ERA) Facility provides a
mechanism for extending the Registry schema to include
data (attributes) for operating systems other than UNIX.
This data includes attribute schema and attribute instances.
These are stored in the Registry and propagated from
the master security server to replicas, just like the
existing Registry data. The attribute schema has a
cell-wide influence, but not an inter-cell influence.
The Extended Registry Attributes (ERAs) are manipulated
by a set of operations for creating and maintaining the
attribute schema and attribute instances.
These operations provide the ability to define attribute
types and attach attribute instances to registry objects.
Registry objects are nodes in the Registry (database) to
which access is controlled by an ACL Manager type.
The Registry Objects are:
-
Principal
-
Group
-
Organisation
-
Policy
-
Directory
-
Replist
-
Attr_schema
These registry objects and their accompanying ACL Manager
type are explained elsewhere in this document.
The ACL Manager types can be seen in
RS Protected Objects and their ACL Manager Types
.
The Extended Registry Attribute (ERA) Facility also
provides a trigger interface that servers use to integrate
their attribute services with the ERA services.
Attribute Schema
An attribute schema is a catalog of attribute types known to a system
(in the sense of "operating system"). Each entry in the schema
defines the format and function of an attribute type.
There is an attribute schema identified by the architectural
name "xattrschema" under the security junction point (usually
"/.:/sec") in the CDS namespace. The schema may be dynamcially
updated to create or destroy schema entries. Access to the
(attribute) schema is controlled by an ACL on the schema object.
(As previously mentioned, the schema is propagated from the master
security server to replicas like other Registry data.)
Since the schema is local to a cell, it defines the types that can
be used within the cell, but not outside the cell (unless the
type is also defined in another cell).
See
Access Control for the xattrschema Object
for information on the ACL object permissions.
- Note:
- When an attribute is used in an authorisation decision, it is
likely that the value of that attribute for a particular principal
must not be the same as the value of that attribute for any
other principal. Therefore, when attributes are used for authorisation
decision, they should be unique. The ERA schema entries have a
"unique" boolean as one of the characteristics of the attribute
type. In order for an attribute to be unique, this boolean must
be set to the value TRUE (1).
Access Control for the xattrschema Object
The Registry ACL Manager has the xattrschema
acl_mgr_type identified by the UUID
755cd9ce-ded3-11cc-8d0a-08009353559
which supports the following set of permission bits:
Permission Bit
| Name
| Description
|
---|
d
| delete
| Delete an entry from the schema
|
i
| insert
| Create a new entry in the schema
|
m
| management
| Modify a schema entry
|
r
| read
| View the contents of the schema
|
c
| control
| Modify the ACL on the schema
|
Table: Extended Attribute Schema ACL Manager Permission Bits
Schema Entries
A schema entry defines the characteristics of an attribute
type known to the system. Once a schema entry has been
created for an attribute type, instances of that attribute
type can be created on objects that are dominated by the
schema.
The primary identifier of an attribute type is its
unique identifier (UUID). The schema entry also contains
a unique string name that can be used as a secondary key.
Although schema entries may be created and deleted
dynamically, only certain fields in the schema entry
may be modified after creation.
The prohibition of certain fields from being modified
after creation avoids inconsistent Registry data and
access control.
The sec_attr_schema_entry_t data type defines a
schema entry. It is shown in
sec_attr_schema_entry_t
.
The following fields in a schema entry (sometimes also
called an attribute type) can be modified:
-
attr_name
-
acl_mgr_set
-
reserved
-
intercell_action
-
trig_binding
-
comment
Additional ACL managers may be added to the acl_mgr_set
field after creation of the entry, but none may be deleted
or changed. If a dramatic change, such as a different
attr_encoding or acl_mgr_type (in the acl_mgr_set),
must be made to an schema entry, the schema entry must first
be deleted (which will force deletion of all attributes of that
type), then re-created.
The acl_mgr_set lists the ACL Manager types that support the
object types on which attributes of a type can be created. For
instance, if an attribute is to be attached to principal objects,
the principal acl_mgr_type must be specified.
Similarly, if the attribute is additionally intended for use on
the policy object, the policy acl_mgr_type must
be specified. For each acl_mgr_type, the permissions
required for attribute operations on the corresponding object
type are also specified. The data type structure for this
is the sec_attr_acl_mgr_info_t, which is defined in
sec_attr_acl_mgr_info_t
.
Attribute Type Flags
Some of the fields in a schema entry are known as flags. Their
settings have special meanings to the entry.
If for instance, the reserved flag is set, the entry
cannot be deleted. If a principal with the required permissions
changes this flag (field), for instance, the cell administrator,
to FALSE (0), then authorized principals can delete the
schema entry.
If the use_defaults flag is TRUE (1), then when searching
for a default attribute value, the DCE 1.1 RS ERA function
first examines the organisation (specified in the principal's
account, if any) for an attribute instance of the requested type.
It secondly inspects the policy object for an attribute instance
of the same type (When a
rs_attr_get_effective()
query is made on a group or organisation object, only the
policy object is inspected for an attribute instance to use as
a default value).
The flags are
defined in the sec_attr_sch_entry_flags_t data type in
sec_attr_sch_entry_flags_t
.
The use_defaults Algorithm
The algorithm used by
rs_attr_get_effective()
(which is not useful for queries on the policy object itself) for
a single-valued attribute type is:
-
Query the named object for an attribute instance of the requested
type. If an instance exists, return it. If an instance is not
found, proceed.
-
If the object is one of the following:
-
a principal without an account
-
a group
-
an organization
proceed. Otherwise (Else), if the object is a principal with
an account, query the organisation specified in the principal's
account for an attribute instance of the requested type.
If an instance exists, return it. If an instance is not found,
proceed.
-
Query the policy object for an attribute of the requested type.
If an instance exists, return it. Otherwise, return
"attribute_not_found".
The search algorithm for a default attribute differs
slightly for a multi_valued (if this flag is TRUE (1))
attribute type.
When an attribute type is defined with both the use_defaults
and the multi_valued flags set, then the same progression
from principal to organisation to policy is made; however,
all attribute instances are collected and returned after the check
on the policy object. Thus, if an attribute instance of the
requested type exists on both the principal object and the policy
object, then
rs_attr_get_effective()
will return two attribute instances for that query.
The use_defaults behavior depends upon support for the
given attribute type on the organisation and policy object types.
For instance, if the schema entry for a given attribute
type does not include the organisation acl_mgr_type
in its acl_mgr_set, then the query on organisation
will be skipped. Likewise, if the attribute type is not
supported on the policy object, the query on the policy
object will be skipped.
The intercell_action Algorithm
The intercell_action field of the schema entry specifies the action
that should be taken by the Privilege Server when reading attributes
from a foreign cell. This field can contain one of three values:
- sec_attr_intercell_act_accept
- Accept the foreign attribute instance.
- sec_attr_intercell_act_reject
- Reject the foreign attribute instance.
- sec_attr_intercell_act_evaluate
- Call a remote trigger server to determine how the attribute
instance should be handled.
When the Privilege Server is generating a PTGT for a foreign principal,
it:
-
retrieves the list of attributes from the foreign principal's EPAC
- Note:
- The attribute instances may be attached to the principal object itself
or attached to the group or organisation object associated with the
principal object.
-
passes the list to the Privilege Server through the *
prv_attr_check_intercell_attrs()
call which retains, discards, or maps the attributes in the list,
producing an output list of attributes
-
includes the output list of acceptable attributes in the EPAC
it generates for the object, for the PTGT for the foreign principal.
The Privilege Server then checks the local attribute schema for the
attribute types with UUIDs that match the UUIDs of the attribute
instances from the foreign cell that are contained in the foreign
principal's EPAC. At this point, the Privilege Server does one of
two things, as follows:
-
If the Privilege Server cannot find a matching attribute type in
the local attribute schema, it checks the unknown_intercell_action
attribute on the policy object. If this attribute is set to:
- Note:
- The unknown_intercell_action attribute must be created by
the system administrator and attaached to the policy object.
The attribute type, which takes the same values as the
intercell_action flag (field), is defined in
Unknown Intercell Action Attribute
.
-
If the Privilege Server finds a matching attribute type in the local
attribute schema, it retrieves the attribute. The action it now
takes depends upon the setting of the attribute type's intercell
action field and unique flag, as follows:
-
If the intercell action field (intercell_action) is set to
the value sec_attr_intercell_act_accept and:
-
The unique flag (field) is set to FALSE (0), the Privilege Server
includes the foreign attribute instance in the principal's EPAC
-
The unique flag (field) is set to TRUE (1), the Privilege Server
includes the foreign attribute instance in the principal's EPAC
only if the attribute instance value is unique among all
instances of the attribute type within the local cell.
- Note:
- If the unique attribute type flag is set to TRUE (1) and a
query trigger exists for a given attribute type, the intercell
action field cannot be set to the value sec_attr_intercell_act_accept
because, in this case, only the query trigger server can reasonably
perform a uniqueness check.
-
If the intercell action (intercell_action) field is set to
the value sec_attr_intercell_act_reject, the Privilege Server
unconditionally discards the foreign attribute instance.
-
If the intercell action (intercell_action) field is set to
the value sec_attr_intercell_act_evaluate, the Privilege Server
makes a remote
sec_attr_trig_intercell_avail()
call to an attribute trigger using the binding information in the
local attribute type schema entry. The remote attribute trigger
determines whether to retain, discard, or map the attribute instance
to another value or values. The Privilege Server includes the values
returned by the attribute trigger in the
sec_attr_trig_query
call output array in the principal's EPAC.
sec_attr_trig_type_flags_t
defines the types and values for schema entry types.
Attribute Scope
The scope field (defined in
sec_attr_schema_entry_t
)
controls the objects to which an attribute type can be attached.
If scope is defined, the attribute can be attached only to
objects defined by the scope. If the scope for a given attribute
is defined as some directory name, instances of that attribute
type can be attached only to objects in that directory.
If the scope is narrowed by fully specifying an object in that
directory, for instance, /directory_name/another_directory_name,
then the attribute can only be attached to the another_directory_name
principal.
Attribute Encodings
Attribute encoding defines the legal encoding for instances of the
attribute type. The encoding controls the format of the attribute
instance values, such as whether the attribute value is an
integer, string, a UUID, or vector of UUIDs that define an attribute set.
Attribute encodings are defined by the sec_attr_encoding_t
data type which can be found in
sec_attr_encoding_t
.
Attribute Triggers
Some extended registry attributes require the support of an
outside server either to verify input attribute values
before storing them (in the Registry Store) or to supply
output values when the data are stored in an external
database.
Such a server could be the connection to a legacy registry
system or could be part of a new security application.
The attribute trigger facility privides for automatic
calls (triggers) to outside DCE servers for certain
attribute operations. More specifically, triggers will
automatically be invoked by the sec_rgy_attr_client
agent whenever an
rs_attr_*()
call indicates that a trigger is required for the operation
to complete. The attribute trigger facility is discussed
in the next section.
Attribute Trigger Facility
The attribute trigger facility consists of three components,
specified as follows:
-
The attribute schema trigger fields (trig_types and
trig_binding), defined in
sec_attr_schema_entry_t
,
which enable the association of a trigger and binding information
with an attribute type. These fields are part of a "standard"
schema entry that defines an attribute type.
-
The sec_attr_trig interface, which defines the query
and update trigger operations. The interface functions are
defined in the
sec_rgy_attr_*()
functions in
Registry API
.
(For instance, for the query operation, the
sec_rgy_attr_*()
function specifies the sec_attr_t attr_value field is
used to pass in optional information
required by the attribute trigger query.)
-
The trigger servers (implemented as DCE servers), independent of
the DCE security server, that implement the trigger operations
for the attribute types configured with their bindings.
The first two components are described in this specificaion, and
are provided as part of the DCE 1.1 extended registry attribute
support.
Trigger servers are written by security application developers.
A trigger may be configured for any attribute type of any encoding
type by filling in the trig_types and trig_binding fields
of the schema entry.
Trigger Binding
When an attribute is created with the
sec_rgy_attr_update()
call (defined in
sec_rgy_attr_update
),
the association between the attribute type and an attribute trigger
is defined by specifying the following:
-
Trigger Type - (Schema entry trig_types)
Defines the trigger as a query server, for query operations; or an
update server, for update operations.
- Notes:
-
If one of these flags (query or update) is set, then schema field
trig_binding must also be set.
-
For DCE 1.1, the "query" and "update" flags are mutually exclusive.
-
Trigger Binding - (Schema entry trig_binding)
Defines the server binding handle for the attribute trigger. The details
of the trigger binding are defined by a number of data types.
The trig_binding field contains an array of bindings, each of
which may be a server directory entry name, a string binding, or
an RPC protocol tower set. It also contains optional authentication
and authorisation information for making authenticated RPC calls.
It is recommended that the trig_binding specify the directory
entry name for the trigger server and that actual address information
be stored in the directory service (Prototype applications may want
to specify a string binding or protocol tower for convenience.).
When a server name is retrieved from the trig_binding field, the
rpc_ns_binding_import_begin()
function may be called specifying the server name, the
rpc_c_ns_syntax_dce()
entry name syntax, and the sec_attr_trig interface handle
to establish a context for importing RPC binding handles from the
name service database.
When a string binding is retrieved, the
rpc_ns_binding_import_begin()
function may be used to generate an RPC binding handle.
Once a binding handle is obtained, the
rpc_binding_set_auth_info()
function may be called with the binding handle and the
authentication information from the trig_binding
field to set authentication and authorisation information
for this handle to the trigger server.
See
sec_attr_bind_auth_info_type_t
for more information on authentication information to be used.
Refer to
sec_attr_schema_entry_t
,
the definition of the sec_attr_schema_entry_t data type, for more
information on these two schema fields.
Only if both of the above fields are specified will the association
between the attribute type and attribute trigger be created. An association
can be defined to any attribute type encoding except an attribute set.
Attribute sets are described in
Attribute Sets
.
Query Triggers
If an attribute type is configured with a query trigger and a
sec_rgy_attr_lookup_*()
of an attribute of that type is performed, the client side attribute
lookup code will:
-
bind to the trigger server (using a binding from the attribute type's
schema entry)
-
make the remote
sec_attr_trig_query()
call, passing in the attribute keys (there can be optional information
in the attr_value field) provided by the caller in the lookup
-
if successful, return the output attribute(s) to the caller.
If a
sec_rgy_attr_update()
function is called for an attribute type with a query trigger, the
input attrubute value is ignored and a "stub" attribute instance
is created on the named object. This serves to mark the existence
of this attribute on the object (nothing else is done). Modifications
to the real attribute value must occur at the trigger server.
Update Triggers
If an attribut type is configured with an update trigger and a
sec_rgy_attr_update()
function is called, the server-side update code will:
-
bind to the triger server (using a binding from the attribute type's
schema entry)
-
make the remote
sec_attr_trig_query()
call, passing in the attributes specified by the caller in the write
-
if successful, store the output attribute(s) in the (ERA) database and
return the output attribute(s) to the caller.
Attribute Sets
Attribute sets provide a flexible method of grouping related attributes
on an object (for easier search and retrieval of related attributes-
For instance, a query on an attribute set expands to a query on its members).
The members of a set are defined in an instance of the attribute set,
whose value is a vector of attribute type UUIDs. Different sets of
members may be defined in each attribute set instance in order to
tailor a set for the object to which it is attached.
- Note:
- Attribute sets may not be nested. A member UUID of an attribute set
may not itself identify an attribute set. This limitation may be
removed in a future version of DCE (newer than DCD 1.1).
The attribute type UUIDss referenced in an attribute set instance must
correspond to existing attribute schema entries. It is possible to
create an attribute set instance on an object, however, before creating
member attribute instances on that object (which might be advisable).
Attribute sets are defined by the sec_attr_enc_attr_set_t data type in
sec_attr_enc_attr_set_t
.
Access Control for Attribute Types
The definition of an attribute type in the schema enables the
creation of attribute instances of the same type with a consistent
format. In general, access to an attribute instance is controlled
by the ACL on the object to which the attribute is attached.
ACLs are not attached to attributes themselves. An attribute is
"just another data field" on the Registry object to which
it is attached. Access to that data field is controlled by
permission bits on the Registry object's ACL. In other words,
access to an attribute instance is controlled by the ACL on
the object to which the attribute instance is attached,
whereas access to a schema entry is controlled by the ACL
on the xattrschema object.
For instance, consider an attribute, A. Suppose it
is attached to a Principal object, P. Then, access
to the A attribute on the P Principal object
is controlled by the ACL on the P object.
Access control for a given attribute type is specified in
the acl_mgr_set (acl_mgr_type and permset
fields) of its schema entry. If a given ACL Manager type
is not specified in the acl_mgr_set, then it is not
possible to attach the attribute to Registry objects that
use that ACL Manager type.
(The ACL Manager types and the permissions they support
are shown in
RS Protected Objects and their ACL Manager Types
.
)
Additional Attribute Permission Bits
The RS ACL Managers have been enhanced to support additional
(generic) attribute type permissions that administrators
may assign for access control for attribute types of their
choice. The set of new permission bits {O, P, Q, ..., X, Y, Z}
are supported by each ACL Manager for each Registry object
type that supports ERAs. Thus, the list of valid permissions
for each ACL Manager shown in
RS Protected Objects and their ACL Manager Types
has been extended with the "O" through "Z" permission bits.
All uses of these additional (O-Z) attribute permission bits
-
in the Access Permsets fields of schema entries
-
on ACLS
-
in policies regarding their use,
will be controlled by the cell administrator. The DCE security
services will not interpret or assign meaning to these bits
other than what is implied by their inclusion in a schema entry.
Access Control on Attributes with Triggers
Access to information maintained by a trigger server is controlled
entirely by that trigger server. The trigger server may choose to
implement any authorisation mechanism (including none).
A query operation on an attribute associated with a query trigger
will undergo the following authorisation checks (the process for
an update trigger is very similar):
-
The
sec_rgy_attr_lookup_by_id()
or other
sec_rgy_attr_*()
query function performs the
rs_attr_*()
query remote call to the security server.
-
The
rs_attr_lookup_by_id()
(or other
rs_attr_*()
query function) will check the ACL of the named object to see if
the client has the required permissions (specified in the query_permset
field of the (acl_mgr_set) field of the schema entry).
If access is granted, the operation returns the trigger binding information
required to perform the
sec_attr_trig_query().
If access is not granted, the operation fails (see the specific function
in
Registry API
)
for specific information about the failure status codes returned.
-
If
sec_attr_trig_query()
rs_attr_*()
query succeeds, the
sec_attr_query*()
function creates an authenticated (with the client's login context)
binding handle to the trigger server and performs the
sec_attr_trig_query().
Upon receiving the
sec_attr_trig_query()
call, the trigger server may inquire of the RPC the client's identity,
perform name-based authentication, perform ACL checks if it implements
an ACL manager, or execute any other access control mechanism it has
in place for the information being accessed.
The trigger server may choose to query the Registry attribute schema
for the query_permset configured for this attribute type, and
use that information in an ACL check (it is however, under no obligation
to so do).
Essentially, the implementation of access controls on attribute information
stored outside of the Registry database is left to the designers of
those applications. This specification does not describe, nor does it
recommend the inforcement of, an authorisation mechanism for (use by)
attribute trigger servers.
Well-Known Attribute Types
Certain definitions, known as "well-known" attribute types,
are required for DCE 1.1 security services. These are
definitions of architectural attribute types that will be used
by the DCE security service to make security policy decisions.
Well-known attributes ahve documented, well-known attribute
type UUIDs (The type UUID is the authoritative key by which such
attributes are known).
Although a standard DCE 1.1 installation may create the schema
entries for well-known attributes as well as instances of those
attributes, nothing can prevent an administrator from deleting them.
Security policy will be affected by the absence of any given
well-known attribute as described by the specification for that
attribute. A cell administrator can easily recreate a schema entry
for a well-known attribute if the type UUID and other characteristics
for it are known.
The DCE 1.1 Extended Registry Attribute facility requires the
well-known "unknown intercell action attribute" for determining
policy that is defined in the next section.
Refer to
The intercell_action Algorithm
for implications of its absence upon the Privilege Server (PS), PSZ,
when reading attributes from a foreign cell.
Unknown Intercell Action Attribute
The DCE 1.1 Extended Registry Attributes facility requires the
creation of the following well-known attribute type for the
policy object:
The intercell_action Algorithm
provides information on the security policy implications of this attribute.
Extended Login and Password Management Overview
For DCE 1.1, login and password management have been improved to
enhance several areas; pre-authentication, login denial, and
password management.
The improvements to login and password management for DCE 1.1
and newer versions include the following:
-
Pre-authentication
-
Login denial through environmental parameters
-
Login denial based upon registry attributes
-
Detection and limitation of invalid login attempts
-
Password strength control.
Pre-Authentication
Passive attacks on user passwords occur when the initial request
for validation sends the login name of the user in the request
and this verifiable plaintext data is returned from the Key
Distribution Service (KDS) encrypted in the user's key in addition
to a TGT. An attacker is able to make an initial request for
validation using the user's name and then proceed to attack the
response by using additional resources to derive the key and
obtain the TGT by trying all combinations until the decryption
yields the verifiable plaintext data sent in the original request.
Pre-authentication, in the generic sense, is a method of
authenticating login attempts that attempts to thwart passive
attacks on the KDS. It requires access to the derived key of a
user to generate the initial request and does not send verifiable
plaintext in the request. If the server is unable to decrypt
the request, the login attempt fails and no credentials are returned.
Prior to DCE 1.1, authentication is particularly vulnerable to
off-line password guessing attacks when users have "weak
passwords" (derived from words). For DCE 1.1 (and newer versions),
there are three protocols used by DCE Security clients and servers
to perform this first part (pre-authentication) of the
user-authentication process. They are as follows:
-
The third-party protocol, which provides the highest level
of security.
-
The timestamps protocol, which is less secure (but still more
secure than the DCE 1.0 protocol).
-
The DCE 1.0 protocol, which is the least secure, and is provided solely
to enable DCE 1.1 Security Servers to process requests from pre-DCE 1.1
clients.
Login Denial
This consists of two aspects-the Client and the Server.
Server
With the addition of pre-authentication, checks which were
previously provided by the client can now be enforced by the server.
Before pre-authentication, the only way a login was known to be
successful was if the client could use the user's derived key to
decrypt the TGT returned from the KDS. Utilising Extended Registry
Attributes (new for DCE 1.1), administrators can now limit the
number of failed login attempts for a principal and also lock an
account if that number is exceeded.
Prior to DCE 1.1, checks for expired passwords were optional. They
were enforced by the client. As of DCE 1.1, the TGT returned from
the KDS is marked as expired if the password expiration time
has been reached or will be reached for the time the ticket is
valid and the rejection of "expired TGT's" will be enforced
by the KDS.
Client
Prior to DCE 1.1, the inability of applications to specify additional
criteria for controlling authentication of users was a weakness
in the authentication mechanism. The presence of ERAs in DCE 1.1
(and newer versions) permits the specification of additional
application specific checks for authentication. An application
may define a "server" function and specify the binding to this
function in an ERA which will be invoked AFTER authentication but
BEFORE returning to the client.
Trigger Binding
specifies details on this topic.
Password Management
User passwords are often cited as the weakest links in any security
system. Control of passwords has been limited prior to DCE 1.1 to
checks performed by the password program on the host machine before
the calls to update the Registry. The only check enforced then
was minimum password length.
Using DCE 1.1 ERAs, additional password controls may be specified
and enforced in the server. In particular, "well-known" ERAs
have been defined to permit application specific server functions
for password strength checking and password generation.
Administrators must specify the binding for these functions in
the ERA and the presence of these ERAs will be checked by the
server on password updates. In addition, ERAs are used to specify
control parameters for the enforcement of limited password reuse.
These "well-known" ERAs are defined in
Schemas for Well-Known Attributes
.
Pre-Authentication and Obtaining a TGT
The protocol used by the Security client when it makes a login request
to the AS is determined as follows:
-
Pre-DCE 1.1 clients always use the DCE 1.0 protocol.
-
DCE 1.1 clients use the third-party protocol, unless the host
machine's session key (which the client uses to construct the request)
is unavailable. It then uses the timestamps protocol.
These protocols will be explained in the descriptions that follow.
The protocol used by the AS to respond to the client is determined by
the following:
-
The protocol used by the client making the login request.
-
The value of a pre_auth_req Extended Registry Attribute (ERA)
attached to the requesting principal.
This can be summarised as follows:
The Authentication Service alsaays attempts to reply using the same
protocol used by the client making the request, unless the value of
the ERA "forbids" it to do so.
The Timestamps (AS + TGS) Protocol
- Note:
- This pre-authentication protocol is also known as PADATA-ENC-TIMESTAMPS.
The timestamps protocol is identical to the DCE 1.0 protocol in
Basic KDS (AS+TGS) Protocol
with the following additions:
-
In step 1 (AS Reguest: Ask for ticket to KDS), Client A
sends to the AS, in addition to the user's name (UUID) (as one of
its arguments (to
sec_login_setup_identity()
), a timestamp encrypted in the user's derived (secret) key.
-
In step 1½ (AS Response: Receive ticket to KDS), the AS,
before preparing the user's TGT, verifies the user as follows:
-
It decrypts the timestamp using the copy of the user's key it
obtained from the Registry.
-
If the decryption succeeeds, and the timestamp is within 5 minutes
of the current time, the user is verified, and the AS proceeds to
prepare the TGT.
If the decryption fails, or if the timestamp is not within 5 minutes
of the current time, the Authentication Service rejects the login
request.
With this protocol the AS can verify that the client login request
is timely and that the requesting client knows the user's password.
It is thus aware of, and can manage, persistent login failures for
a given user, eliminating passive password-guessing attacks.
Details about this will be given later in this discussion.
Note, however, that with this protocol, since the timestamp is
identifiable text and the key for encryption is the user's
derived key, it is still vulnerable to off-line attacks by
processes monitoring network requests (although it eliminates
the passive attacks made by sending bogus initial requests
for validation).
The Third-Party (AS + TGS) Protocol
- Note:
- This pre-authentication protocol is also known as PADATA-ENC-THIRD-PARTY.
The third-party protocol addresses both types of attacks
mentioned previously-passive attacks made by sending bogus
initial requests for validation (iteratively), and off-line
attacks by processes (monitoring network requests).
This protocol uses a strong "third party" key to encrypt the
padata in the request. (Thus, since it is a pre-authentication
mechanism and it uses a "strong session key" (instead of the
user's secret key) for encryption, it addresses the previously
mentioned attacks.) The strong key is provided each machine running
as a DCE client. They thus have access to a strong 56-bit DES
key which is shared with the KDS.
Client Side
When a client principal is
about to initiate a KRB_AS_REQ (initial authentication exchange
with the KDS), it must first obtain the information it needs to
compose the request. This information is as follows:
-
First, the client (A) must obtain the TGT for the machine principal
on which it is executing. Client A's process must have special
privileges (usually termed, a "privileged" process) in order to obtain
the machine principal TGT. "Privileged" in the sense meant here
refers to, say, a program in a standard UNIX operating system that
runs as a setuid to the root process. "Privileged" in terms of
non[??]IX systems is beyond the scope of this document.
- Note:
- If the login application itself is "privileged", it has access to
the machine principal TGT and construct this part of the request itself.
If not, it obtains the following from "sec_clientd":
-
The TGT.
-
A random key encrypted in the Machine Session Key (a strong key)
otherwise known as the user's derived key.
-
A random key to be shared between itself and the KDS.
If sec_clientd is not available, which is the case when initially
configuring a cell, then a third-party request cannot be
generated and the protocol defaluts to the timestamps
protocol.
-
Second, the user's derived key must be constructed using the
user's supplied password and a "salt". The password is known
by Client A and the "salt" is, in most cases a default
value.
- Note:
- To reduce the number of RPC's necessary in the usual case, Client A
will attempt to generate the user's derived key using the default salt.
On a login failure, the server (KDS) will check to see if Client A
uses a non-default salt, and if so, will return this "non-default"
salt with the error. Client A will detect the presence of this
salt and retry the login using the "non-default" salt.
-
Third, the client (Client A) generates a random key to use as
a shared key between itself and the KDS for the reply (called the
"reply random key").
Now that the required information is obtained, Client A must
compose the padata block. To do this, Client A takes the
current time and the "reply random key" and encrypts this data
using the user's derived key. It then takes the random key
and encrypts the data a second time.
The padata now consists of the machine TGT, the random key
encrypted in the Machine Session Key and an encrypted data block.
The machine TGT identifies the third party sponsor for the exchange
and the reply random key established a shared key between the
login application (referred to herin as Client A) and the KDS.
Signature of padata Field
The padata field constructed as described in the preceeding
section, has the signature below. For items denoted as "X"
the meaning is to be interpereted as "X" is encrypted
using "" as a key. Also, "msk" is shorthand for
"machine session key", and "uk" is shorthand for
"user's derived key". Lastly, "rk" is shorthand for "random key".
[[machine-TGT][(random-key)msk][(([timestamp][reply-random-key])uk)rk]]
Figure: Signature of the KDS padata Field
Server Side
On the KDS, the principal database is extended with an Extended Registry
Attribute pre_auth_req that determines if that principal must use
pre-authentication. This is a "well-known" ERA, defined in
Schemas for Well-Known Attributes
,
whose allowable
values are (relating to if the principal must use pre-authentication):
-
0-NONE-(Denotes no pre-authentication)
-
1-PADATA-ENC-TIMESTAMPS-(Denotes timestamps protocol)
-
1-PADATA-ENC-THIRD-PARTY-(Denotes third-party protocol)
When processing a request, the KDS server examines the pre_auth_req ERA
for the selected principal. If the request satisfies the restriction,
then the server will provide the corresponding reply.
There is an implicit hierarchy in the ERA values for pre-aauthentication.
The KDS will only reject requests if the ERA contains a value more
restrictive than the actual request.
Thus, if Client A initiates a KRB_AS_REQ in the third-party
protocol form and the the client principal has an ERA with a value of
PADATA-ENC-THIRD-PARTY, the restriction is satisfied and the login is
successful (all other things being equal), so the reply will be a TGT
encrypted in the random-reply-key.
If however, a DCE 1.1 KDS servr receives a DCE 1.0 (no pre-authentication)
KRF_AS_REQ from Client A whose principal has an ERA with the value
of PADATA-ENC-THIRD-PARTY, the restriction is not satisfied and the request
will be denied.
If the ERA for a principal contains the value NONE, but the principal
logs in from a DCE 1.1 client, this client (Client A for reference
purposes), Client A will generate a pre-authentication
request (KRB_AS_REQ) specifying PADATA-ENC-THIRD-PARTY, and send it
to the KDS. The KDS will accept this request because PADATA-ENC-THIRD-PARTY
is a stronger authentication mechanism than specified in the ERA
(pre_auth_req).
On the other hand, if the scenario were reversed and the ERA value was
PADATA-ENC-THIRD-PARTY, and the request came from a DCE 1.0 client
with no pre-authentication support, the login attempt would fail
since the authentication mechanism is less secure than that specified
in the ERA.
Note that if an initial KRB_AS_REQ is denied, it may be because a salt
other than the default was used to generate the user's derived key.
The KDS (server) can determine if the default salt was used and if
a non-default salt was used and the decryption of the request
fails, the KDS will issue a KRB_ERROR reply containing the correct
salt retrieved from the Registry. Client A can then repeat
the construction of the padata and retry the KRB_AS_REQ.
(The KRB_ERROR has the status KDC_PREAUTH_FAILED.)
Thus, there are two reasons Client A's initial KRB_AS_REQ
can fail. They are as follows:
-
The salt used to derive the user's key is a value other than the default.
-
The ERA on the client principal has a protocol more restrictive than
that used in the request.
Third-Party Pre-Authentication Protocol
Pre-Authentication Protocol for KDS
illustrates the steps in the
sec_login_*()
functions that support pre-authentication using the third-party
protocol. (
The Timestamps (AS + TGS) Protocol
describes the timestamps protocol.)
In the figure, step 1 is shown simply to note that while previously,
sec_login_setup_identity()
initiated the KRB_AS_REQ to the (AS function of the) KDS, this
functionality is now (in DCE 1.1 and newer versions) being accomplished by
the two functions
sec_login_validate_identity()
and
sec_login_valid_and_cert_ident().
Step 2 is also initiated by a DCE 1.1 Client, Client A, in terms
of the terminology of
Basic KDS (AS+TGS) Protocol
(Basic KDS (AS+TGS) Protocol).
In step 3, the AS portion of the KDS will check for the existence
of a pre_auth_req ERA and return the value of the ERA along
with the "salt"
(used for encryption of the user's password).
In step 4, Client A uses the returned information in order to
perform step 5.
This (step 5) step corresponds to the bullet item
A -> AS: A, KDS, LA,KDS,
NA,AS
in
Basic KDS (AS+TGS) Protocol
where step 1 (AS Request: Ask for ticket to KDS) is performed.
In step 6 (which corresponds to bullet item
A <­ AS: A, {KDS, KA,KDS,
LA,KDS, NA,AS}KA,
TktA,KDS
of
Basic KDS (AS+TGS) Protocol
where in step
1½ (AS Response: Receive ticket to KDS) a response is sent
to Client A for the KRB_AS_REQ it sent to the KDS),
the KDS attemptss to decrypt the request. If successful, the
KRB_AS_REP returned to Client A will contain a TGT.
If the decryption fails, a KRB_ERROR (KDC_PREAUTH_FAILED)
is returned and the login attempt is terminated.
If the decryption is successful, the login sequence contines
(at step 2 (TGS Request: Ask for ticket to server)
in
Basic KDS (AS+TGS) Protocol
).
Figure: Pre-Authentication Protocol for KDS
Environmental Parameters and Registry Attributes
Authentication checks performed by application servers may require
additional information about the application user to determine
whether or not the user is authorised to use the application.
Examples of such information might include items such as the following:
-
physical location
-
user's timezone
-
ID of user's machine (where logged on)
-
type of connection from user to Client machine.
New features for DCE 1.1, delegation and Extended Registry Attributes,
provide an underlying mechanism to provide for additional application
specific information being securely attached to a client principal's
credentials. Along with this, changes made in the
sec_login_*()
functions support pre-authentication. These include changes
to
sec_login_validate_identity()
and
sec_login_valid_and_cert_identity().
These changes are discussed in
Third-Party Pre-Authentication Protocol
.
The mentioned functions are in
Login API
.
Several "well-known" Extended Registry Attribute sets called:
-
environment_set,
-
login_set and
-
policy_check_set.
are provided in DCE 1.1 to assist in pre-authentication.
In addition, when it has been determined that an invalid login
attempt has occurred (has been detected
by the Security Server), two "well-known" ERAs
are defined to limit the impact of password attacks.
They permit
an administrator to control two aspects of the user's
authentication by:
-
Setting a maximum number of consecutive bad attempts allowed
before an account is locked (the max_invalid_attempts ERA).
This is an integer that reflects the number (minus one) of
login attempts allowed before a principal is disabled from
login attempts. A single successful login to an account
resets the number of bad attempts.
-
Specifying a time to disable an account once the maximum number
of attempts (at login) has been reached. This ERA is known as
the disable_time_interval ERA.
The time is specified in seconds. It can also be specified as
FOREVER if manual administrative action is the desired policy.
These "well known" ERAs are defined in
Schemas for Well-Known Attributes
.
Password Management
Prior to DCE 1.1, the following password strength policies were
supported:
-
minimum password length (default 0)
-
whether a password can be all spaces (default YES)
-
whether a password can be all alphanumeric (default YES).
As of DCE 1.1, known deficiencies with user-defined passwords
such as common names, reuse, and so on, have been restricted
by password management options that include the following:
-
Non-trivial password strength checking
The pwd_val_type ERA has been provided to assist in this. It contains
the following values:
-
NONE
No password checking is necessary.
-
USER_SELECT
A user must supply a password.
-
USER_CAN_SELECT
A user can supply a password or an "*" to indicate they would like
the system to generate a password for them.
-
GENERATION_REQUIRED
User input will be ignored.
See next item.
(For USER_SELECT and USER_CAN_SELECT values, individual sites can
specify a binding for the server exporting the interface as described in
Trigger Binding
,
"Trigger Binding".)
-
Password generation
If the value of the pwd_val_type ERA is GENERATION_REQUIRED,
a strong password will be generated. As with the USER_* values,
individual sites can replace the supplied password generation server
with one of their own.
-
Password reuse checking
To assist in this, two "well-known" ERAs are defined-
minimum_password_cycle_time (the time in minutes before
passwords can be reused) and passwords_per_cycle
(the limit on the number of previous passwords).
Users are not permitted to change their passwords more often than
the passwords_per_cycle times during minimum_password_cycle_time.
Password Expiration
Previously (prior to DCE 1.1), whenever a password expired, the Client
determined whether or not to allow logins. With the advent of DCE 1.1,
the KDS will terminate a login attempt if the password is expired.
The "well-known" passwd_override ERA has been defined in
DCE 1.1 to permit a principal assigned the ERA to login even if their
password has expired. This ERA should be configured by default on
the administrator principal so that an administrator will not be locked
out from getting tickets.
It is recommended by this specification that user principal accounts
use the default action which enforces the password expiration.
Schemas for Well-Known Attributes
The following prototype schema entries illustrate the "well-known"
ERAs mentioned in this document. They are all of the
sec_attr_schema_entry_t data type defined in
sec_attr_schema_entry_t
.
These "well-known" ERAs share certain characteristics. The
axl_mgr_set, for instance, identifies princ, org
and policy. It is intended that "well-known" ERAs are
set on different objects in order to permit either fine or rough
granularity of enforcement. For instance, regular users might
have a disable_time_interval ERA of 1 day, since it is
conceivable they could have a bad day and exceed their max_invalid_attempts
allocation.
Thus, instances of the disable_time_interval ERA with a value
of "1" might be created on the org and policy object.
But, if an attack is made on the admin principal, installations
would want to know about it. This can be handled by creating a
f2disable_time_interval value of "forever" on this principal
(forcing a manual intervention if max_invalid_attempts
is exceeded).
To permit this granularity, the apply_defaults field (of the ERA)
must be set to "TRUE". It is important to specify how access is
controlled to attribute instances, and this is done by the ACL
on the object to which the attribute is attached. Access control
is specified in the acl_mgr_set, which consists of an
acl_mgr_type (say principal) and permset (say m) of
a schema entry.
The intent is that "principals" should not be able to change or
delete these "well-known" ERAs. Only those that possess
the "m" permission should be permitted to access the ERAs.
The syntax of the acl_mgr_set schema (entry) is as follows:
acl_mgr_type:Query/Update/Test/Delete
disable_time_interval ERA
attr_name: "disable_time_interval"
attr_uuid: 63005af0-dd2d-11cc-946f-080009353559
attr_encoding: INTEGER
acl_mgr_set:
princ:m/m/m/m
org:m/m/m/m
policy:m/m/m/m
unique:FALSE
multi-valued: FALSE
reserved:TRUE
apply_defaults: TRUE
intercell_action:
trig_types:
trig_binding:
comment: "amount of time in minutes to disable account"
max_invalid_attempts ERA
attr_name: "max_invalid_attempts"
attr_uuid: 657eb68c-dd2d-11cc-8990-080009353559
attr_encoding: INTEGER
acl_mgr_set:
princ:m/m/m/m
org:m/m/m/m
policy:m/m/m/m
unique:FALSE
multi-valued: FALSE
reserved:TRUE
apply_defaults: TRUE
intercell_action:
trig_types:
trig_binding:
comment: "number of invalid attempts allowed before locking account"
minimum_password_cycle_time ERA
attr_name: "minimum_password_cycle_time"
attr_uuid: 66513166-dd2d-11cc-9db5-080009353559
attr_encoding: INTEGER
acl_mgr_set:
princ:m/m/m/m
org:m/m/m/m
policy:m/m/m/m
unique:FALSE
multi-valued: FALSE
reserved:TRUE
apply_defaults: TRUE
intercell_action:
trig_types:
trig_binding:
comment: "minutes before password can be reused"
passwords_per_cycle ERA
attr_name: "passwords_per_cycle"
attr_uuid: 67090868-dd2d-11cc-a84d-080009353559
attr_encoding: INTEGER
acl_mgr_set:
princ:m/m/m/m
org:m/m/m/m
policy:m/m/m/m
unique:FALSE
multi-valued: FALSE
reserved:TRUE
apply_defaults: TRUE
intercell_action:
trig_types:
trig_binding:
comment: "limit on number of previous passwords within minimum password cycle time"
pwd_val_type ERA
attr_name: "pwd_val_type"
attr_uuid: 689843ce-dd2d-11cc-a3e1-080009353559
attr_encoding: INTEGER
acl_mgr_set:
princ:m/m/m/m
org:m/m/m/m
policy:m/m/m/m
unique:FALSE
multi-valued: FALSE
reserved:TRUE
apply_defaults: TRUE
intercell_action:
trig_types:
trig_binding:
comment: "{0=NONE, 1=USER_SELECT, 2=USER_CAN_SELECT, 3=GENERATION_REQUIRED}"
password_generation ERA
attr_name: "password_generation"
attr_uuid: 69b421a6-dd2d-11cc-bac5-080009353559
attr_encoding: BINDING
acl_mgr_set:
princ:m/m/m/m
org:m/m/m/m
policy:m/m/m/m
unique:FALSE
multi-valued: FALSE
reserved:TRUE
apply_defaults: TRUE
intercell_action:
trig_types:
trig_binding:
comment: "binding to server exporting the sec_login_password_generate interface"
pwd_mgmt_binding ERA
attr_name: "pwd_mgmt_binding"
attr_uuid: 6a93b8f2-dd2d-11cc-9be7-080009353559
attr_encoding: BINDING
acl_mgr_set:
princ:m/m/m/m
org:m/m/m/m
policy:m/m/m/m
unique:FALSE
multi-valued: FALSE
reserved:TRUE
apply_defaults: TRUE
intercell_action:
trig_types:
trig_binding:
comment: "binding to server exporting the sec_pwd_mgmt_binding interface"
pre_auth_req ERA
attr_name: "pre_auth_req"
attr_uuid: 6c9d0ec8-dd2d-11cc-abdd-080009353559
attr_encoding: INTEGER
acl_mgr_set:
princ:m/m/m/m
org:m/m/m/m
policy:m/m/m/m
unique:FALSE
multi-valued: FALSE
reserved:TRUE
apply_defaults: TRUE
intercell_action:
trig_types:
trig_binding:
comment: "{0=NONE, 1=PADATA-ENC-TIMESTAMPS, 2=PADATA-ENC-THIRD-PARTY}"
passwd_override ERA
attr_name: "passwd_override"
attr_uuid: bc51691e-dd2d-11cc-9866-080009353559
attr_encoding: INTEGER
acl_mgr_set:
princ:m/m/m/m
org:m/m/m/m
policy:m/m/m/m
unique:FALSE
multi-valued: FALSE
reserved:TRUE
apply_defaults: TRUE
intercell_action:
trig_types:
trig_binding:
comment: "{0=NONE, 1=OVERRIDE}"
login_set ERA
attr_name: "login_set"
attr_uuid: 6d8d97bc-dd2d-11cc-b1cc-080009353559
attr_encoding: attr_set
acl_mgr_set:
princ:m/m/m/m
org:m/m/m/m
policy:m/m/m/m
unique:FALSE
multi-valued: FALSE
reserved:TRUE
apply_defaults: TRUE
intercell_action:
trig_types:
trig_binding:
comment: "standard set of attributes to be returned on login"
environment_set ERA
attr_name: "environment_set"
attr_uuid: ba4a5824-dd2d-11cc-a9f3-080009353559
attr_encoding: attr_set
acl_mgr_set:
princ:m/m/m/m
org:m/m/m/m
policy:m/m/m/m
unique:FALSE
multi-valued: FALSE
reserved:TRUE
apply_defaults: TRUE
intercell_action:
trig_types:
trig_binding:
comment: "attached to machine principals; standard set of environment attributes"
[??] Some characters or strings
that appear in the printed document are not easily
representable using HTML.
Please note that the html version of this specification
may contain formatting aberrations. The definitive version
is available as an electronic publication on CD-ROM
from The Open Group.