Previous section.

DCE 1.1: Authentication and Security Services
Copyright © 1997 The Open Group

Privilege (Authorisation) Services

This chapter specifies the privilege (or authorisation), services supported by DCE, together with the protocols associated with them. Currently, two such services are supported, namely PAC-based Privilege Service (PS) and Name-based Privilege Service. Of these two, PAC-based authorisation used to be the more important and better supported, and most of this chapter is devoted to it. With the advent of delegation, extensions have been made to the PAC in order to support delegation controls and extensible restrictions. These extend the notion of identity to include chained identities, and to allow delegation and extensible restrictions to be specified.

In addition, the extensions also include certain attributes, those dealing with the data repository or registry. Including them as extensions to the PAC, designated EPAC, permits them to be transmitted securely and automatically along with a principal's identity information.

In order to ensure the integrity of the data being transmitted across the network in a delegated environment, name-based authorization is used. This is because specific attributes must be requested and examined prior to transmission. Name-based authorisation is treated briefly at the end of the chapter.

Throughout this chapter the notation ps_request_*(), wherever it appears, is used in a generic sense to mean any one of ps_request_ptgt(), ps_request_eptgt(), ps_request_become_delegate(), or ps_request_become_impersonator() as appropriate. In addition, where it is used elsewhere in this document, it is used in the same sense.

For an overview of this chapter, see Kerberos Key Distribution (Authentication) Service (KDS) through Cells-Cross-cell Authentication and Authorisation of this specification -which are considered a prerequisite for this whole chapter.

PAC-Based Privilege Service (PS)

The PS is a distributed, partitioned RPC service, instantiated by a (conceptually unitary, but potentially replicated) RPC server in each cell Z, denoted PSZ. If the name of cell Z is, say, /.../cellZ, then the RPC service name of PSZ (used for RPC binding purposes) is determined from /.../cellZ/cell-profile via the rpriv interface UUID and version number (specified in The rpriv RPC Interface ) -typically, the name associated with this profile element will be /.../cellZ/sec, which will be an RPC server group pointing to the individual (replicated) PSZ server(s). (The principal names of PS servers (used for security purposes)- as opposed to their RPC server names-are introduced later in this chapter.)

The rpriv RPC Interface

Each PS server, PSZ, supports the following RPC interface: 

 

[uuid(b1e338f8-9533-11c9-a34a-08001e019c1e), version(1.1),
 pointer_default(ptr)]
interface rpriv {
 /* begin running listing of rpriv interface */
ps_message_t

This is the definition of the encoding used for the data in the PTGS Request/PTGS Response message pair by which clients acquire privilege-ticket-granting-tickets. (See PTGS Service .) 

    typedef struct {
        unsigned32                      count;
        [size_is(count)] byte           bytes[];
    }                                       ps_message_t;
ps_attr_request_t

This is the definition of the structure to encapsulate information relevant to an optional auxiliary attributes request from the privilege server (PS). 

    typedef struct {
        unsigned32              count_auxiliary_attribute_keys;
        [ptr, size_is(count_auxiliary_attribute_keys)]
            sec_attr_t          *auxiliary_attribute_keys;
    }                                       ps_attr_request_t;
ps_attr_result_t

This is the definition of the structure to encapsulate information relevant to an optional auxiliary attributes response from the privilege server (PS). 

    typedef struct {
        error_status_t      status;
        unsigned32          count_attrs;
        [ptr, size_is(count_attrs)]
            sec_attr_t      *attrs;
    }                                       ps_attr_result_t;
ps_app_tkt_result_t

This is the definition of the structure to encapsulate information relevant to an optional application service ticket response used for delegation-for extended-privilege-ticket-granting-tickets, as well as for becoming a delegate or an impersonator on behalf of a client. 

    typedef struct {
        error_status_t             status;
        [ptr] ps_message_t         *application_ticket_result;
    }                                        ps_app_tkt_result_t;
ps_request_ptgt

    void
    ps_request_ptgt (
        [in]  handle_t                      rpc_handle,
        [in]  unsigned32                    authn_service,
        [in]  unsigned32                    authz_service,
        [in]  ps_message_t                  *request,
        [out] ps_message_t                  **response,
        [out, ref] error_status_t           *status 
);

The semantics of ps_request_ptgt() are that a client, C, invokes ps_request_ptgt() to "send a PS Request message" to a PS server, PSZ; C receives a PS Response message from PSZ when ps_request_ptgt() returns. Its parameters are the following:


ps_request_become_delegate

 

void 
ps_request_become_delegate (
  [in]  handle_t                      rpc_handle,
  [in]  unsigned32                    authn_service,
  [in]  unsigned32                    authz_service,
  [in] sec_id_delegation_type_t       delegation_type_permitted,
  [in] sec_id_restriction_set_t       *delegate_restrictions,
  [in] sec_id_restriction_set_t       *target_restrictions,
  [in] sec_id_opt_req_t               *optional_restrictions,
  [in] sec_id_opt_req_t               *required_restrictions,
  [in] sec_id_compatibility_mode_t    compatibility_mode,
  [in] sec_bytes_t                    *delegation_chain,
  [in] sec_bytes_t                    *delegate,
  [in] sec_encrypted_bytes_t          *delegation_token,
  [in, ref]  ps_message_t             *request,
  [out] ps_message_t                  **response,
  [out] sec_bytes_t                   *new_delegation_chain,
  [in, ptr] ps_attr_request_t         *auxliary_attribute_request,
  [out] ps_attr_result_t              *auxliary_attribute_result,
  [in, ptr, string] unsigned char     *application_ticket_request,
  [out] ps_app_tkt_result_t           *application_ticket_result,
  [out, ref] error_status_t           *status
 );

The semantics of ps_request_become_delegate() are that an intermediary caller (on behalf of a Client, C,) invokes ps_request_become_delegate() to "send a PS Request message" to a PS server, PSZ for an entire delegation chain. The delegation chain includes the EPAC(s) and associated Delegation Token (DT) from the intermediary's caller, along with the intermdiary's EPAC and PS Request message. The PS Server, PSZ, once it ensures that no tampering has taken place (by verifying that the Delegation Token for the delegation chain is correct), will create a new delegation chain from the existing one with the intermediary's EPAC as a new delegate. If any EPAC(s) in the chain have a delegate restriction preventing this intermediary (server) from transmitting it's identity, the PS server will replace that participant's EPAC with an anonymous EPAC. (See Anonymous Identity ).

The intermediary caller receives a PS Response message from PSZ when ps_request_become_delegate() returns. This response pertains to the delegation chain. The PS Response message will contain a seal in the A_D field encrypted in the key of the privilege server, PSZ, as the new delegation token for this delegation chain. In addition, the A_D field will also contain the seal of the EPAC chain. This seal is an MD5 checksum for each EPAC in the chain, and an MD5 checksum of those checksums.

The parameters of ps_request_become_delegate() are the following:

ps_request_become_impersonator

 

void 
ps_request_become_impersonator (
  [in]  handle_t                      rpc_handle,
  [in]  unsigned32                    authn_service,
  [in]  unsigned32                    authz_service,
  [in] sec_id_delegation_type_t       delegation_type_permitted,
  [in] sec_id_restriction_set_t       *delegate_restrictions,
  [in] sec_id_restriction_set_t       *target_restrictions,
  [in] sec_id_opt_req_t               *optional_restrictions,
  [in] sec_id_opt_req_t               *required_restrictions,
  [in] sec_bytes_t                    *delegation_chain,
  [in] sec_bytes_t                    *impersonator,
  [in] sec_encrypted_bytes_t          *delegation_token,
  [in]  ps_message_t                  *request,
  [out] ps_message_t                  **response,
  [out] sec_bytes_t                   *new_delegation_chain,
  [in, ptr] ps_attr_request_t         *auxliary_attribute_request,
  [out] ps_attr_result_t              *auxliary_attribute_result,
  [in, ptr, string] unsigned char     *application_ticket_request,
  [out] ps_app_tkt_result_t           *application_ticket_result,
  [out, ref] error_status_t           *status
);
The semantics of ps_request_become_impersonator() are that an intermediary caller (on behalf of a Client, C,) invokes ps_request_become_impersonator() to "send a PS Request message" to a PS server, PSZ for the initiator's EPAC (The initiator's EPAC includes the EPAC(s) and associated Delegation Token (DT) from the intermediary's caller), along with the intermediary's EPAC and PS Request message. The PS Server, PSZ, once it ensures that no tampering has taken place (by verifying that the Delegation Token for the initiator's EPAC is correct), will then verify that the intermediary is permitted to impersonate the initiator.

The intermediary caller receives a PS Response message from PSZ when ps_request_become_impersonator() returns. This response pertains to the impersonator's EPAC. The PS Response message will contain a seal of the initiator's EPAC in the A_D field. This seal is an MD5 checksum for the initiator's EPAC. In addition, the A_D field will also contain that same seal encrypted in the key of the privilege server, PSZ, as the new delegation token for the impersonators's EPAC.

The parameters of ps_request_become_impersonator() are the following:

ps_request_eptgt

 

void
ps_request_eptgt (
  [in]  handle_t                      rpc_handle,
  [in]  unsigned32                    authn_service,
  [in]  unsigned32                    authz_service,
  [in] sec_bytes_t                    *requested_privileges,
  [in]  ps_message_t                  *request,
  [out] ps_message_t                  **response,
  [out] sec_bytes_t                   *granted_privileges,
  [in, ptr] ps_attr_request_t         *auxliary_attribute_request,
  [out] ps_attr_result                *auxliary_attribute_result,
  [in, ptr, string] unsigned char     *application_ticket_request,
  [out] ps_app_tkt_result_t           *application_ticket_result,
  [out, ref] error_status_t           *status
);
The semantics of ps_request_eptgt() are that a client, C, invokes ps_request_eptgt() using name-based authorisation to ensure the integrity of the parameters across the network to "send a PS Request message" to a PS server, PSZ; C receives a PS Response message containing an Extended PAC (EPAC) from PSZ when ps_request_ptgt() returns. The PS Request message may optionally request specific attributes. The parameters of ps_request_eptgt() are the following: 
 

} /* end running listing of rpriv interface */

Registered Authentication Services

The currently registered values for authn_service are the following:

Registered Authorisation Services

The currently registered values for authz_service are the following:

Status Codes

[RFC 24.2: 2.]

The following status codes (transmitted as values of the type error_status_t) are specified for the rpriv interface. Only their values are specified here-their use is specified elsewhere in this specification. See RFC 24.2 for details of how the status code values are determined. Within that context, the base value for the component security whose mnemonic is "sec", translates into the base value, in hex, of 17122. For any given message, the last three digits appended to this base are the actual index value into the message catalog (in hex) of that message. 

const unsigned32     sec_priv_s_server_unavailable    = 0x1712205a;
const unsigned32     sec_priv_s_invalid_principal     = 0x1712205b;
const unsigned32     sec_priv_s_not_member_any_group  = 0x1712205c;
const unsigned32     sec_priv_s_invalid_authn_svc     = 0x1712205e;
const unsigned32     sec_priv_s_invalid_authz_svc     = 0x1712205f;
const unsigned32     sec_priv_s_invalid_trust_path    = 0x17122060;
const unsigned32     sec_priv_s_invalid_request       = 0x17122061;
const unsigned32     sec_priv_s_deleg_not_enabled     = 0x17122065;
const unsigned32     sec_priv_s_intercell_deleg_req   = 0x17122069;
const unsigned32     sec_rgy_not_implemented          = 0x17122072;
const unsigned32     sec_rgy_server_unavailable       = 0x1712207b;

Status Code Origination

The status codes in the preceedng section can possibily be set by the following functions. Note this is a probable source of the code, and as such does not restrict a specific code to that particular function in a future revision of DCE.

Status Code Possible Origin
sec_priv_s_server_unavailable ps_request_get_ptgt()
   
sec_priv_s_invalid_principal ps_request_get_ptgt()
   
sec_priv_s_not_member_any_group ps_request_ptgt()
   
sec_priv_s_invalid_authn_svc ps_request_ptgt()
ps_request_become_delegate()
ps_request_become_impersonator()
ps_request_eptgt()
   
sec_priv_s_invalid_authz_svc ps_request_ptgt()
ps_request_become_delegate()
ps_request_become_impersonator()
ps_request_eptgt()
   
sec_priv_s_invalid_trust_path ps_request_ptgt()
ps_request_eptgt()
   
sec_priv_s_invalid_request ps_request_ptgt()
   
sec_priv_s_deleg_not_enabled ps_request_become_delegate()
ps_request_become_impersonator()
   
sec_priv_s_intercell_deleg_req ps_request_become_delegate()
   
sec_rgy_not_implemented ps_request_become_delegate()
ps_request_become_impersonator()
ps_request_eptgt()
   
sec_rgy_server_unavailable ps_request_ptgt()

Table: Possible Source of rpriv RPC Interface Status Codes

PTGS Service

PS servers support just one service, which is associated with a pair of request/response messages (for definitions relating to privilege-ticket-granting-tickets, see Privilege-Tickets ):

Thus, a PS Request message is a PTGS Request message, and a PS Response message is a PTGS Response message.

Privilege-Tickets

Privilege-tickets are the (trusted) information objects that the PS manages (their relationships with ps_request_*() are given later in this chapter).

Privilege-tickets are the "same" as non-privilege-tickets (as specified in Key Distribution (Authentication) Services ), with the following three supplements (for details see Privilege-Tickets ):

Since privilege-tickets are special kinds of tickets, the terminology and other specifications of Key Distribution (Authentication) Services relating to tickets applies with appropriate modification of detail to the privilege-tickets of this chapter-and this will be understood to be in force by default unless explicitly indicated otherwise. In particular, the following notation can and will be used without more elaborate high-level explanation than that given here (the low-level details are given in the remainder of this chapter, of course):

Note that the privilege-ticket acquired via ps_request_eptgt() to a PS server PSZ is always a privilege-ticket-granting-ticket (targeted to the KDS server KDSZ in the same cell Z), never a privilege-ticket targeted to a non-KDS server (those are obtained from KDS servers, not PS servers).

Data Types

The data type definitions of Key Distribution (Authentication) Services remain in effect for this chapter, and in addition the following data types are defined. The data description languages and encodings used are ASN.1/BER/DER and IDL/NDR (see the referenced Open Group DCE 1.1 RPC Specification for the latter), which can be distinguished from one another by their syntaxes. The representations from Authorisation Identities through Pickled PACs are identified by the following interface: 

 

[
 uuid(47EAABA3-3000-000-0D00-01DC6C000000)
]

Authorisation Identities

Identities suitable for the DCE authorisation architecture are represented by the sec_id_t data type, which is defined as follows: 

 

typedef struct {
    uuid_t                              uuid;
    [string, ptr] char                  *name;
}                                           sec_id_t;

Its semantics are that it indicates the identity of security entities -principals (including KDS principals; that is, "cell identities"), groups, and so on-for the purposes of the authorisation subsystem. Its fields are the following:

Note:
Authentication identities must be carefully distinguished from authorisation identities in DCE. The former are represented by stringnames (client name and server name), and their semantics are defined in Key Distribution (Authentication) Services ; the latter are represented by UUIDs, and their semantics are defined in this chapter and in Access Control Lists (ACLs) and ACL Managers . As will be seen in the remainder of this chapter, PAC-based authorisation decisions made by servers in the DCE environment depend only on authorisation identities, not authentication identities, because the client's authentication identity is not (securely) transmitted to the server (the "client name" authentication identity that is transmitted is that of the PS, not the accessing client principal)-hence, in this sense, DCE service requests are sometimes said, by abuse of language, to be "anonymous" (with respect to authentication identities). Name-based authorisation decisions, on the other hand, do depend on authentication identity stringnames, not on UUIDs-see Name-Based Authorisation .
Security-Version (Version 2) UUIDs

The UUIDs that appear in the uuid field of sec_id_t must be security-version (or "version 2") UUIDs, in all cases except :

These security-version UUIDs are specified exactly as in Appendix A, except that they have the following special properties and interpretations:

By this embedding of local host IDs in (security-version) UUIDs, local host identity information (privilege attributes) can be derived from UUIDs in an especially straightforward and efficient manner (as opposed to, say, going through an auxiliary ID mapping table, maintained either on the local host or elsewhere). (The embedding of local host IDs is specified above in the particular case of POSIX hosts; the embedding in the case of non-POSIX systems is not currently specified in DCE.)

Concerning the uniqueness of security-version UUIDs, see the discussion in Privilege (Authorisation) Service (PS) of the double-UUID identification scheme. The point of that discussion is that the security architecture of DCE depends upon the uniqueness of security-version UUIDs only within the context of a cell; that is, only within the context of the local RS's (persistent) datastore, and that degree of uniqueness can be guaranteed by the RS itself (namely, the RS maintains state in its datastore, in the sense that it can always check that every UUID it maintains is different from all other UUIDs it maintains). In other words, while security-version UUIDs are (like all UUIDs) specified to be "globally unique in space and time", security is not compromised if they are merely "locally unique per cell". This statement does not relax the requirements on implementations of security-version UUIDs, it is only a comment about the trust structure of DCE, namely, entities (security subjects and objects) need not trust that foreign RSs maintain globally unique UUIDs, only that their own local RS maintains locally unique UUIDs.

Note that the manner in which security-version UUIDs are generated is implementation-dependent: no API routine is supported by DCE that generates security-version UUIDs (recall that uuid_create() specified in the referenced Open Group DCE 1.1 RPC Specification generates only version 1 UUIDs).

Local and Foreign Authorisation Identities

Foreign identities are represented by the sec_id_foreign_t, which is defined as follows: 

 

typedef struct {
  sec_id_t                     id;
  sec_id_t                     cell;
}                              sec_id_foreign_t;

Its semantics are that it indicates a "foreign" (as opposed to "local") entity for authorisation purposes. Here, "local" (resp., "foreign") are relative (context-dependent) terms, indicating entities registered in the RS of the same (resp., different) cell as some other (specified) entity. Cells themselves, as well as other local identities, are represented by the sec_id_t data type; foreign identities are represented by sec_id_foreign_t. In any specific application of these notions, the entity relative to which the local/foreign distinction is being made must be unambiguously specified.

The fields of the sec_id_foreign_t data type are the following:

Groups Associated With a Foreign Cell

Foreign group sets are represented by the sec_id_foreign_groupset_t, which is defined as follows: 

 

typedef struct {
sec_id_t                            cell;
unsigned16                          count_local_groups;
[size_is(count_local_groups), ptr]
sec_id_t                            *local_groups;
}                                   sec_id_foreign_groupset_t;

Its semantics are that it indicates a set of groups that are all associated with the same "foreign" entity for authorisation purposes. In that sense, the groups are "local" to the entity, and are registered in the RS of the same cell. Thus, the groups within this entity are represented by the sec_id_t data type.

The fields of the sec_id_foreign_t data type are the following:

PAC Formats

PAC formats are represented by the sec_id_pac_format_t data type, which is defined as follows: 

 

typedef enum {
    sec_id_pac_format_v1 /* 0 */
}                                      sec_id_pac_format_t;

Its semantics are that it identifies the format of PACs (defined in Privilege Attribute Certificates (PACs) ) in use. The currently supported formats are:

Privilege Attribute Certificates (PACs)

Privilege attribute certificates are represented by the sec_id_pac_t data type, which is defined as follows: 

 

typedef struct {
  sec_id_pac_format_t                     pac_format;
  unsigned32                              authenticated;
  sec_id_t                                cell;
  sec_id_t                                principal;
  sec_id_t                                primary_group;
  unsigned16                              count_local_groups;
  unsigned16                              count_foreign_groups;
  [size_is(count_local_groups), ptr]
      sec_id_t                            *local_groups;
  [size_is(count_foreign_groups), ptr]
      sec_id_foreign_t                    *foreign_groups;
}                                               sec_id_pac_t;

Its semantics are that it indicates authorisation attributes (or characteristics) which are "projected" (sent in a message) from a client to a server during a service request. Its fields are the following:

The significance of the principal and group attributes (authorisation identities) in the PAC is that servers use them for access authorisation purposes (see Common Access Determination Algorithm ).

Pickled PACs

Pickled PACs are represented by the sec_id_pickled_pac_t data type, which is defined to be a sec_id_pac_t pickle. In the terminology and notation of (IDL/NDR) Pickles , this pickle's type UUID (H.pkl_type) is d9f3bd98-567d-11ca-9ec6-08001e022936, and its body bgcolor="#FFFFFF" datastream is an NDR-marshalled sec_id_pac_t.

As mentioned in Registered Authorisation Data Types , the authorisation data type authzDataType-PAC is represented by a sec_id_pickled_pac_t.

Privilege-Tickets

Privilege-tickets are represented by the PrivilegeTicket data type, which is defined as follows: 

 

PrivilegeTicket ::= Ticket

Its semantics are identical with that of Ticket's, with the following three supplementary semantics:

Privilege Authentication Headers

Privilege authentication headers are represented by the PAuthnHeader data type, which is defined as follows: 

 

PAuthnHeader ::= AuthnHeader

Its semantics are identical with that of AuthnHeader's, with the following supplementary semantics:

(Note that the client named in authnHdr-EncryptedAuthnr (authnHdr-EncryptAuthnr.authnr-ClientCell and authnHdr-EncryptAuthnr.authnr-ClientName) identifies the the PS server named in the privilege-ticket, not the calling client A.)

Privilege Reverse-Authentication Headers

Privilege reverse-authentication headers are represented by the PRevAuthnHeader data type, which is defined as follows: 

 

PRevAuthnHeader ::= RevAuthnHeader

Its semantics are identical with that of RevAuthnHeader's. In particular, it does (securely) identify the server to the client on the basis of its authentication identity (stringname).

PTGS Requests

PTGS Requests are represented by the PTGSRequest data type, which is defined as follows: 

 

PTGSRequest ::= TGSRequest

Its semantics are that it indicates a request for a privilege-ticket-granting-ticket.

Note:
As seen in PTGS Request/Response Processing , the semantics of a PTGS Request/Response pair differ somewhat from that of a TGS Request/Response pair, particularly with respect to the interpretation (or lack thereof) of some of the data fields transmitted by the client in the request body bgcolor="#FFFFFF" (denoted ptgsReq.req-Body in PTGS Request/Response Processing ), which are simply ignored by the target PS server (this is the case for the options field, ptgsReq.req-Body.req-Flags, and the data fields associated with its flag bits). This situation could be expressed by saying that "certain information is `lost' when passing from the authentication environment to the authorisation environment". An argument could therefore be made that the present PTGS Request format (PTGSRequest = TGSRequest) is "overkill", and that a simpler format, transmitting a smaller amount of data, would be sufficient to effect the required semantics of a PTGS Request (and a similar argument could be made for the format of PTkts). Nevertheless, while such an argument may be reasonable, that isn't what is actually done (partially for historical reasons), as specified in this chapter.

PTGS Responses

PTGS Responses are represented by the PTGSResponse data type, which is defined as follows: 

 

PTGSResponse ::= TGSResponse

Its semantics are that it indicates a returned privilege-ticket-granting-ticket.

PS Errors

There is no special "PSError data type" (analogous to the KDSError data type). All errors encountered in ps_request_*() are reported via its status parameter.

Extended PAC (EPAC) Interface

This is the base set of definitions that extend the PAC in order to support delegation. This extended PAC (EPAC) contains the identity and group membership information present in a DCE 1.0 format PAC. In addition, it contains optional delegation controls, optional and required restrictions, and extended attributes which are certified by means of being sealed in an EPAC by the privilege server (PS).

The following EPAC interface defines the base type definitions of the data supported by each PS server, PSZ, for DCE Version 1.1 and newer versions. 

 

[
    uuid(6a7409ee-d6c0-11cc-8fe9-0800093569b9)
]
interface sec_id_epac_base { /* Begin sec_id_epac_base Interface */
Optional and Required Restrictions

Optional and required restrictions are represented by the sec_id_opt_req_t, which is defined as follows: 

 

typedef struct {
    unsigned16                 restriction_len;
    [size_is(restriction_len), ptr]
        byte                   *restrictions;
} sec_id_opt_req_t;
Entry Types for Delegate and Target Restrictions

The entries for delegate and target restrictions are defined by the sec_rstr_entry_type_t, which follows: 

 

typedef enum {
  sec_rstr_e_type_user,     /* POSIX 1003.6                     */
                            /* Entry contains a key identifying 
                             * a user                           */

  sec_rstr_e_type_group,    /* POSIX 1003.6                     */
                            /* Entry contains a key identifying 
                             * a group                          */
  sec_rstr_e_type_foreign_user,
                            /* Entry contains a key identifying 
                             * a user and the foreign realm     */
  sec_rstr_e_type_foreign_group,
                            /* Entry contains a key identifying 
                             * a group and the foreign realm    */
  sec_rstr_e_type_foreign_other,
                            /* Entry contains a key identifying 
                             * a foreign realm.  Any user that
                             * can authenticate to the foreign
                             *  realm will be allowed access.   */
  sec_rstr_e_type_any_other,
                            /* Any user that can authenticate to 
                             * any foreign realm will be allowed 
                             * access.                          */
  sec_rstr_e_type_no_other
                        /* No other user is allowed access. */
}                         sec_rstr_entry_type_t;
Delegate and Target Restriction Types

Optional and required restrictions are defined by the sec_id_restriction_t, which follows: 

 

typedef struct {
  union sec_id_entry_u
  switch (sec_rstr_entry_type_t entry_type) tagged_union {
  case sec_rstr_e_type_any_other:
  case sec_rstr_e_type_no_other:
   /* Just the tag field */;
  case sec_rstr_e_type_user:
  case sec_rstr_e_type_group:
  case sec_rstr_e_type_foreign_other:
    sec_id_t id;
  case sec_rstr_e_type_foreign_user:
  case sec_rstr_e_type_foreign_group:
    sec_id_foreign_t foreign_id;
  }                                     entry_info;
}                               sec_id_restriction_t;
Set of Delegation and Target Restrictions

The set of delegation or target restrictions is represented by the sec_id_restriction_set_t which is defined as follows: 

 

typedef struct {
    unsigned16 num_restrictions;
    [ptr, size_is(num_restrictions)]
        sec_id_restriction_t *restrictions;
}                            sec_id_restriction_set_t;
Delegation Compatibility Modes

Delegation compatibility modes determine which EPAC from the delegation chain, if any, to convert and insert into the V1.0 PAC portion of the Authorization Data field. They are defined by the sec_id_compatibility_mode_t, which follows: 

 

typedef unsigned16 sec_id_compatibility_mode_t;
const unsigned16 sec_id_compat_mode_none      = 0;
const unsigned16 sec_id_compat_mode_initiator = 1;
const unsigned16 sec_id_compat_mode_caller    = 2;
Supported Delegation Types

Delegation may take the forms permitted in the sec_id_delegation_type_t, which is defined by the selections that follow: 

 

typedef unsigned16 sec_id_delegation_type_t;
const unsigned16 sec_id_deleg_type_none          = 0;
const unsigned16 sec_id_deleg_type_traced        = 1;
const unsigned16 sec_id_deleg_type_impersonation = 2;
Supported Seal Types

The seal for a DCE 1.1 (and newer versions) EPAC is defined by the sec_id_seal_type_t, which follows. For delegation tokens, the type is sec_id_seal_type_md5_des: 

 

typedef unsigned16 sec_id_seal_type_t;
const unsigned16 sec_id_seal_type_none    = 0;
const unsigned16 sec_id_seal_type_md5_des = 1;
const unsigned16 sec_id_seal_type_md5     = 2;
EPAC Seal

The seal (cryptographic checksum) over the EPAC is defined by the sec_id_seal_t, and is performed by the privilege server (PS) when the EPAC is generated. The sec_id_seal_t definition follows: 

 

typedef struct {
    sec_id_seal_type_t seal_type;
    unsigned16 seal_len;
    [size_is(seal_len),ptr]
        byte *seal_data;
} sec_id_seal_t;
Privilege Attributes for the EPAC

The sec_id_pa_t data type provides for inclusion of privilege attributes in an Extended PAC (EPAC). By including attributes within an EPAC, they may be transmitted securely and automatically along with a principal's identity information. The definition of the sec_id_pa_t follows: 

 

typedef struct {
    sec_id_t realm;
    sec_id_t principal;
    sec_id_t group;
    unsigned16 num_groups;
    [size_is(num_groups), ptr]
        sec_id_t *groups;
    unsigned16 num_foreign_groupsets;
    [size_is(num_foreign_groupsets), ptr]
        sec_id_foreign_groupset_t *foreign_groupsets;
} sec_id_pa_t;
Handle for Privilege Attribute Data

The sec_cred_pa_handle_t definition which follows, provides a handle for the opaque privilege attribute data. Direct access to an EPAC is not supported. This handle provides an interface to permit applications to abstract the contents of an EPAC. 

 

typedef void *sec_cred_pa_handle_t;
Cursor for Delegate Iteration

The sec_cred_cursor_t provides an input or output cursor that can be used to iterate through a set of delegates via the sec_cred_get_delegate() or sec_login_cred_get_delegate() calls. It is initialized with a call to sec_cred_initialize_cursor() or sec_login_cred_initialize_cursor(). 

 


 typedef void *sec_cred_cursor_t;
Cursor for Extended Attributee Iteration

sec_cred_attr_cursor_t provides an input or output cursor used to iterate through a set of extended attributes using calls to sec_cred_get_extended_attributes(). It is initialized with a call to sec_cred_initialize_attr_cursor(). 

 


typedef void *sec_cred_attr_cursor_t;
Extended PAC Data

The extended PAC (EPAC) data is defined by the sec_id_epac_data_t, which follows: 

 

typedef struct {
    sec_id_pa_t                 pa;
    sec_id_compatibility_mode_t compat_mode;	
    sec_id_delegation_type_t    deleg_type;
    sec_id_opt_req_t            opt_restrictions;
    sec_id_opt_req_t            req_restrictions;
    unsigned32                  num_attrs;
    [size_is(num_attrs), ptr]
        sec_attr_t              *attrs;
    sec_id_restriction_set_t    deleg_restrictions;
    sec_id_restriction_set_t    target_restrictions;
} sec_id_epac_data_t;
This data type extends the notion of identities to include chained identities, and also permits delegation and extensible restrictions to be specified. In addition, arbitrary attributes are included within the EPAC. This permits them to be transmitted securely and automatically along with a principal's identity information.

Arbitrary in this context means they are freeform and do not necessarily have a clear cell boundary.

List of Seals

This is the definition for a list of seals. It is represented by the sec_id_seal_set_t, which follows: 

 

typedef struct {
    unsigned32               num_seals;
    [size_is(num_seals), ptr]
        sec_id_seal_t        *seals;
}  sec_id_seal_set_t;

typedef [ptr] sec_id_seal_set_t *sec_id_seal_set_p_t;
When traced delegation is in use, there may be a set of Extended PACs (EPACs) to transmit. Since the EPAC set consists of one EPAC for the initiator and one EPAC for each delegate involved in the operation, a single seal in the PTGT is no longer sufficient to guarantee the individual integrity of each EPAC as well as the integrity of the specific order of the EPACs. To obtain this integrity, the A_D field portion of a PTGT carries the seal of the ordered list of EPAC seals.
Extended PAC (EPAC)

This is the definition of the Extended PAC (EPAC). It is represented by the sec_id_epac_t, which follows: 

 

typedef struct {
    sec_bytes_t 		pickled_epac_data;
    [ptr] sec_id_seal_set_t	*seals;
} sec_id_epac_t;
Set of Extended PACs (EPACs)

This is the definition of the set of Extended PACs (EPACs). It is represented by the sec_id_epac_set_t, which follows: 

 

typedef struct {
    unsigned32               num_epacs;
    [size_is(num_epacs), ptr]
        sec_id_epac_t        *epacs;
} sec_id_epac_set_t;
} /* End sec_id_epac_base Interface */

The sec_cred API for Abstracting EPAC Contents

This API is provided for retrieval of Privilege Attribute information from Extended PACs since direct access to EPACs is not supported in this specification. 

 

[ local ]

interface sec_cred {            /* Start of sec_cred interface */
Anonymous Identity

The following self-defining constants represent the definitions for the Anonymous Cell UUID, Anonymous Principal UUID and Anonymous Group UUID. 

 

const char * SEC_ANONYMOUS_PRINC = "fad18d52-ac83-11cc-b72d-0800092784e9";
const char * SEC_ANONYMOUS_GROUP = "fc6ed07a-ac83-11cc-97af-0800092784e9";
const char * SEC_ANONYMOUS_CELL  = "6761d66a-cff2-11cd-ab92-0800097086e0";
These UUIDs represent well known anonymous identities-cell, principal and group. These UUIDs ensure that any implementation using them will have the same representations for the anonymous cell, principal and anonymous group UUIDs. These are non-security-version UUIDs ("version 1" UUIDs) as specified in Appendix A, Universal Unique Identifier, of the referenced Open Group DCE 1.1 RPC Specification). They have the following properties:

The sec_cred API for Abstracting EPAC Contents provides the descriptions for the rest of the interface functions defined in this sec_cred interface. Since these functions are provided at the API level, their descriptions will not be repeated here. The functions that comprise this interface are also listed in . 

 

}                     /* End of sec_cred interface  */

Delegation Token (Version 0) Format

A delegation token consists of an expiration date and a byte stream. See Delegation Token for its representation. The first byte of any delegation token byte stream is a version number. The contents of subsequent bytes depends upon the version number.

As of DCE1.1, version 0 is the only valid delegation token version. The content of a version 0 delegation token byte stream is illustrated in the following figure.

Figure: Version 0 Delegation Token Format

Its fields have the following properties:

Version 0 Token Flags

This is the definition of the confidential bytes for the Version 0 delegation token: 

 

const unsigned8 sec_dlg_token_v0_conf_bytes = 0x1;

Delegation Token

This is the representation of the sec_dlg_token_t data type: 

 

typedef struct {
    unsigned32 expiration;
    sec_bytes_t token_bytes;
} sec_dlg_token_t;
Its semantics are that it is inserted into the A_D field of a new PTGT by the Privilege Server, PSZ, to ensure that the proper steps were taken to enable delegation, and that none of the data has been tampered with since that time. Its fields are:

Delegation Token Set

This is the representation of the sec_dlg_token_set_t data type: 

 

typedef struct {
    unsigned32 num_tokens;
    [size_is(num_tokens), ptr]
        sec_dlg_token_t *tokens;
} sec_dlg_token_set_t;
Its semantics are that it represents the set of tokens involved in a request. Its fields are:

RS Information

Every PSZ requires access to certain (non-volatile) information. Such information is held in the RSZ datastore, not in the PSZ itself. Some of this information is, with appropriate modification of detail, the same as that held in RSZ for the use of KDSZ. (But note that such information held in the RS datastore for the PS servers, while similar in kind to that held for KDS servers, may be of different values-for example, the KDS may allow renewable tickets, while the PS may not allow renewable privilege-tickets.) Additionally, the following information in the RSZ datastore, which has no analog for the KDSZ, is held solely for use by PSZ:

PTGS Request/Response Processing

This section specifies in detail the processing that occurs during a PTGS Request/Response exchange. That is, this section specifies the issuing of privilege-ticket-granting-tickets. There are three steps involved:

  1. A client prepares a PTGS Request and sends it to a PS server.

  2. A PS server receives the PTGS Request from a client, processes it, prepares a PTGS Response (success case) or diagnostic information (failure case), and returns that to the client.

  3. A client receives a PTGS Response (status = error_status_ok) or PS error (status != error_status_ok).

The details of the three steps of the success case are specified next. (For the failure case, see PS Error Processing .) By specification, it is, with appropriate modification of detail, identical to TGS Request/Response Processing , with the supplements specified in the present section being made.

Throughout the description of PTGS request/response processing, there are two essentially different cases to be considered:

Client Sends PTGS Request

Consider a client A in cell X which has in its possession a non-privilege-ticket targeted to the PS in cell Y (possibly X = Y), TktA,X,···,Y,PSY (containing session key KA,PSY, of encryption type encType). (This TktA,X,···,Y,PSY must not be a PTktA,PSY- PSY must reject such a PTGS Request.) And suppose A wants to present this TktA,X,···,Y,PSY to PSY, and receive in return a privilege-ticket-granting-ticket "based on" TktA,X,···,Y,PSY, PTktA,KDSY, which nominates A, names PSY, and targets KDSY. That is, A wants to send to PSY a PTGS Request, ptgsReq (a value of the data type PTGSRequest), containing TktA,X,···,Y,PSY (ahTkt, in its ptgsReq.req-AuthnData field as the authnHdr.authnHdr-Tkt field of an authentication header authnHdr), and receive in response a PTGS Response, ptgsResp (a value of data type PTGSResponse) containing PTktA,KDSY (ptgsTkt, in its ptgsResp.resp-Tkt field). A prepares ptgsReq in the same way as a TGSRequest message (see Client Sends TGS Request ) with the supplements indicated below, and "sends it" (that is, calls ps_request_*()) to PSY.

PS Server Receives PTGS Request and Sends PTGS Response

Consider a PTGS Request, ptgsReq, received by PSY from A. Thus, ptgsReq is a value of data type PTGSRequest. Then PSY behaves the same way that KDSY behaves when it receives a TGSRequest message (see KDS Server Receives TGS Request and Sends TGS Response ), with the supplements indicated below. (Recall also the description in Privilege (Authorisation) Service (PS) of the PSY's implementation-dependent use of KDSY's long-term key, KKDSY: if PSY does not have knowledge of KKDSY, it may need to send a TGS Request to KDSY in order to get PTktA,KDSY protected by KKDSY.) In the success case, PSY returns a PTGSResponse to A; in the failure case it returns an error diagnostic (status != error_status_ok).

Client Receives PTGS Response

Consider a client A that receives a PTGS Response, ptgsResp (that is, ptgsResp is a value of data type PTGSResponse), in response to a PTGS Request, ptgsReq (as a result of calling ps_request_*()) to PSY. A processes ptgsResp in the same way as a TGS Response (see Client Receives TGS Response ), with the supplements indicated below. In the success case, A is justified in believing that the returned PTktA,KDSY (or ptgsTkt; that is, ptgsResp.resp-Tkt) is correctly and securely targeted to KDSY, and that it contains the values returned elsewhere in the ptgsResp (in particular, the authorisation data attributed to A (ptgsResp.resp-AuthnData)), and using it (especially, its session key, which is denoted K~A,KDSY) in subsequent TGS Requests to KDSY for privilege-tickets. In the failure case, A takes (application-specific) recovery action.

Privilege (Reverse-)Authentication Header Processing

This section specifies in detail the processing that occurs during a privilege authentication/reverse-authentication header exchange. There are three steps involved:

  1. A client prepares a privilege authentication header and sends it to a server as part of a "privilege authentication request for (RPC) service" (for example, this could be a TGS Request for a privilege-ticket, in which case the server is a KDS server). Typically, this privilege authentication header will be merely a part of the whole message sent from client to server, and the rest of the message will contain RPC protocol information and the input parameters for the RPC service request.

  2. A server receives a privilege authentication header from a client, processes it, prepares a privilege reverse-authentication header (in the case of a successful client-to-server privilege authentication, and the client has requested the mutual authentication option) or an error message (in the case of a failed client-to-server privilege authentication), and returns that to the client (though some servers may not return errors depending on their policy). Typically, in the success case, the server will proceed to perform the requested service (subject to authorisation constraints that it decides on the basis of the PAC transmitted in the privilege authentication header) and return the output RPC parameters to the client.

  3. A client receives a privilege reverse-authentication header (success case, if it had requested mutual authentication in its privilege authentication header) or an error (failure case). Typically, in the success case, it also receives the results of its RPC service request, which it will then decide to accept or reject (on the basis of the privilege reverse-authentication header).

The details of the three steps of the success case are specified next. By specification, it is, with appropriate modification of detail, identical to (Reverse-)Authentication Header Processing , with the supplements specified in the present section being made.

Note:
As noted in (Reverse-)Authentication Header Processing , the descriptions here are "typical" of privilege authentication/reverse-authentication header processing, but since the interpreters (A and B) of the authentication/reverse-authentication headers are in general application-specific, this whole discussion should be understood to implicitly accommodate some such wording as "··· or other such processing as the application requires or allows ···".

Client Sends Privilege Authentication Header

Consider a client A in cell X which has successfully obtained a privilege-ticket to a server in cell Y (possibly X = Y). Thus, A is in possession of a privilege-ticket (possibly a privilege-ticket-granting-ticket), pTkt, targeted to a server B in cell Y, whose contents A knows, especially its session key KA,B (and its encryption type encType), and now A wants to use this privilege-ticket to "privilege-authenticate to" (that is, engage in protected communications with, and "project" (transmit) privilege attributes to) server B in cell Y. Then A prepares a privilege authentication header, pAuthnHdr (a value of the PAuthnHeader data type) containing pTkt (pAuthnHdr.authnHdr-Tkt), and a newly generated authenticator authnr (pAuthnHdr.authnHdr-EncryptAuthnr, of type Authenticator), in a way similar to an authenticator (see Client Sends Authentication Header ) and sends it to B, with the supplements indicated below.

Note:
Even though A sets authnr's client cell and client name (authnr.authnr-ClientCell and authnr.authnr-ClientName) to A's cell name (that is, X's cell name) and to PSX's RS name, respectively, these cannot be trusted by the recipient, B. The only identities B can trust are those carried in the ticket, pAuthnHdr.authnHdr-Tkt (that is, pTkt), which are PSY's cell name and RS name (in pTkt.tkt-EncryptPart.tkt-ClientCell and pTkt.tkt-EncryptPart.tkt-ClientName) and A's PAC (in pTkt.tkt-EncryptPart.tkt-AuthzData).

Server Receives Privilege Authentication Header and Sends Privilege Reverse-Authentication Header

Consider a privilege authentication header, pAuthnHdr (a value of the data type PAuthnHeader), received by a server B, containing a privilege-ticket, pAhTkt (pAuthnHdr.authnHdr-Tkt), and an authenticator, authnr (pAuthnHdr.authnHdr-EncryptAuthnr). (For example, KDS servers receive such a privilege authentication header in an entry of the authentication data field of a TGS Request (tgsReq.req-AuthnData[i].authnData-Value for some i >= 0)-see KDS Server Receives TGS Request and Sends TGS Response .) Then B processes pAuthnHdr similarly to the processing of an authenticator header (see Server Receives Authentication Header and Sends Reverse-Authentication Header ), with the supplements indicated below. In the success case, the privilege authentication header "authorises the client A to the server B" (but it does not "authenticate" A to B in the sense of stringname authentication discussed in Key Distribution (Authentication) Services , because the stringname of A is not necessarily projected to B).

Client Receives Privilege Reverse-Authentication Header

Consider a privilege reverse-authentication header, pRevAuthnHdr (a value of the data type PRevAuthnHeader), received by a client A, in response to a privilege authentication header, pAuthnHdr (with the mutual authentication option selected), that A had earlier sent to a server B. Then A processes pRevAuthnHdr exactly as the processing of a reverse-authentication header (see Client Receives Reverse-Authentication Header ), with no supplements at all. In the success case, the privilege reverse-authentication header "authenticates the server B to the client A", exactly as a (non-privilege) reverse-authentication header does (by stringname).

TGS Request/Response Processing (By KDS)

TGS Request/Response Processing persists to be completely valid (that is, it doesn't change at all), in the case that a client presents a privilege-ticket-granting-ticket (as opposed to an ordinary ticket-granting-ticket) to the KDS server to which it is targeted, thereby requesting the KDS to issue a privilege-ticket. Namely, the TGS Subservice of the KDS is "blissfully unaware" of the existence of the PS. The KDS simply issues tickets exactly as described in Key Distribution (Authentication) Services (especially, the "blind copying" of authorisation data), and those tickets then "just happen" to be privilege-tickets by virtue of the very definition of privilege-tickets (namely, their named client is a PS server, they carry the nominated client's PAC authorisation data, and their transit path is empty). Therefore, no supplements at all to TGS request/response processing need be specified here to support "TGS request/response processing (by the KDS)"; that is, to support the issuing of privilege-tickets by the KDS.

PS Error Processing

This section specifies in detail the processing that occurs when a PS server encounters a failure during its processing of a PS Request, and returns a PS error to the requesting client.

Consider a PS Request, psReq, received by PSY from a client A. PSY performs the algorithm specified in PTGS Request/Response Processing , and if it encounters one or more algorithmic failures, it chooses one to return in the status parameter of ps_request_*() (recall, there is no special PSError data type, or "PS Error message").

Cross-cell Authorisation-Vetting the Privilege-ticket-granting-ticket

As seen in PTGS Request/Response Processing , PSY's processing of the PAC of a client A in cell X is quite straightforward if X = Y. But the case X != Y requires that PSY vet the privilege-ticket-granting-ticket in the following two senses:

These two activities have already been discussed in context above, and need have no more said about them here.

Name-Based Authorisation

Note:
Name-based authorisation is included in DCE for support of legacy applications only, and its use for any other purpose is discouraged.

By name-based authorisation is meant authorisation of a client A in cell X to a server B in cell Y, on the basis of a non-privilege-ticket TktA,X,Z´,···,Z´´,Y,B instead of a privilege-ticket PTktA,B, by means of the KDS authentication protocols specified in Key Distribution (Authentication) Services . That is, PS servers are not visited during name-based authorisation. Thus, the only "authorisation" information that is projected from A to B is the transit path (kdsTkt.tkt-EncryptPart.tkt-TransitPath) and the "authentication" stringname of A (kdsTkt.tkt-EncryptPart.tkt-ClientCell and kdsTkt.tkt-EncryptPart.tkt-ClientName -see Key Distribution (Authentication) Services ).

DCE does not specify a suite of supporting facilities for name-based authorisation as it does for PAC-based authorisation. Therefore, an application (that is, a client/server pair) that chooses to use name-based authorisation must take upon itself the responsibility of dealing with the following issues in an application-dependent way:

All-in-all, while name-based authorisation may be of some use to some legacy applications, it should be avoided in favor of PAC-based authorisation for new applications (and even legacy applications should be migrated to PAC-based authorisation, if that is at all feasible, in order that they may participate seamlessly in the DCE security environment).

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