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:

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:

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:

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:

  1. 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)

  2. 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):

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:

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"):

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):

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:

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:

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

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:


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:

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:

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:

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

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:

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):

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)

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.

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:

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 Entries and their Types

An ACLE consists of:

The ACLE Types are organised into the following taxonomy:

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) ):

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:

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:

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:

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:

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 ):

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 ):

Notes on Common ACL Manager ACLs
Notes:

  1. 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.

  2. 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:

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 .

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 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:

The sec_acl API consists of the following routines:

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:

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):

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:

  1. an unreplicated RS server

  2. replicated "master/slave" RS servers (one update replica and multiple query replicas)

  3. "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.)

The RS supports the rs_policy RPC interface for operating on property and policy information, which supports the following operations:

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:

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".

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:

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:

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:

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:

Thus, what the ID Map Facility does is give a bidirectional mapping- pgo-name <-&#62; pgo-ID or:

/.../cell-name/cell-relative-pgo-name <-&#62; <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:

The sec_id API supports the following routines:

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:

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):

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.

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:

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:

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:

  1. the need for such a notion

  2. 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:

  1. 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)

  2. 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:

  1. 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)

  2. addressed to a trusted transport endpoint on which the SCD is listening (see above)

  3. 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:

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:

  1. 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.

  2. 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.

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:

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:

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:

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:

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:

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:

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:

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:

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:

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.

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:

  1. All implementations must implement these id's as specified in the just referenced section to ensure interoperability.

  2. 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.

  3. 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:

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:




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:




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:




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:

    

    

  1. 
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
.

    


    

  2. 
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:


    



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 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:




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:




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:



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




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):



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





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:



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:






The protocol used by the AS to respond to the client is determined by
the following:




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:


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:

    

    

  1. 
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":

      

      

    1. 
The TGT.

      

    2. 
A random key encrypted in the Machine Session Key (a strong key)
otherwise known as the user's derived key.

      

    3. 
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.

    


    

  2. 
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.

    


    

  3. 
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):




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:



 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 <&#173; 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:




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:





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:




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:




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:



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.





Contents
Next section
Index