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
For an overview of this chapter, see
-
-
[uuid(b1e338f8-9533-11c9-a34a-08001e019c1e), version(1.1),
pointer_default(ptr)]
interface rpriv {
/* begin running listing of rpriv interface */
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
typedef struct {
unsigned32 count;
[size_is(count)] byte bytes[];
} ps_message_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;
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;
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;
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
RPC binding handle, bound by the client C to a PS server PSZ.
The authentication (or key distribution) service for which
this invocation of
The authorisation service for which this invocation of
(Pointer to) PS Request message. It has length (*request).count
and value (*request).bytes[]. See
(Pointer to pointer to) PS Response message. It has length
(**response).count and value
(**response).bytes[].
See
(Pointer to) status code. See
-
-
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
The intermediary caller receives a
PS Response message from PSZ when
The parameters of
RPC binding handle, bound by the client C to a PS server PSZ.
The authentication (or key distribution) service for which
this invocation of
The authorisation service for which this invocation of
Determines the delegation type to be permitted. This is specified
by the client when it permits delegation to be enabled. Only
two types are permitted-traced delegation or
impersonation. An intermediary (server) is not permitted to
use a delegation type that was not enabled by the initiator. For
the data type definitions, see
(Pointer to) the list of delegates that are permitted. Delegate
restrictions are set by a client and limit the servers that may
act as an intermediary for the client. The restriction is imposed
by the PS when constructing a new PTGT that permits the intermediary
to operate as a delegate for the client. For more information
see
(Pointer to)
the list of targets to whom this identity may be presented.
The restrictions are placed by a given client to restrict
the set of targets to whom the client's identity may be projected.
These restrictions are imposed by the PSZ of the cell Z
(the target cell). For more information
see
(Pointer to)
the list of (application defined) optional restrictions denoting
specific authorization requirements. These restrictions may be
set by initiators and delegates and apply to the delegation
context (they are interpreted and enforced by the target server
application). A server is free to ignore any optional restriction
that cannot be interpreted.
See
(Pointer to)
the list of (application defined) required restrictions denoting
specific authorization requirements. These restrictions may be
set by initiators and delegates and apply to the delegation
context (they are interpreted and enforced by the target server
application). A server must reject requests for which there is
a required restriction that cannot be interpreted.
See
Specifies the compatibility mode desired when operating on DCE 1.0
servers. The extensions to the PAC required by delegation are not
understood by DCE 1.0 servers. This parameter determines the
contents of the of the start of the Authorization Data (A_D)
field. See
(Pointer to)
a set of chained EPACs. This set of (one or more) EPACs is
encrypted in the same session key used to ensure the privacy
of the arguments in the RPC call, if the authenticated RPC
call is using protect level packet_privacy (more specifically,
rpc_c_protect_level_pkt_privacy, listed in
Note that for DCE 1.1, the chain of EPACs must all reside in the same cell. Thus, if a delegation request traverses outside the cell - for instance, from cell A to cell B, no further delegation is permitted - that is, a server in cell B may perform the function requested, but may not delegate the request to any other server.
(Pointer to)
the EPAC for the intermediary that is issuing the
(Pointer to) he encrypted seal of the EPAC chain. It consists of an MD5 checksum over the checksums for each EPAC in the chain of EPACs (known as the seal of the EPACs), encrypted in the key of the Privilege Server (PSZ). This encrypted checksum is inserted into the A_D field of the EPAC in order to be passed along with the Authorization Data, in any requests (authenticated RPC calls) made subsequent to this call to other servers.
(Pointer to) PS Request message. It has length (*request).count
and value (*request).bytes[]. See
(Pointer to pointer to) PS Response message. It has length
(**response).count and value
(**response).bytes[].
See
(Pointer to)
a chain constructed from the existing (input to this function)
one with the intermediary's EPAC as a new delegate. As noted
previously, the input delegation chain may be modified if
any EPACs in the chain have a delegate restriction preventing
this intermediary server (making this
(Pointer to) types of attributes.
Auxiliary attributes only have meaning in local requests to the PS.
This is an optional parameter which specifies instances of the types
of attributes to be searched for on the node of the principal for whom
(Pointer to) the results obtained from the search for instances of types of attributes specified in auxiliary_attribute_request. For this version of DCE (DCE 1.1), auxiliary attributes are not implemented. Upon return, this parameter is set to the value sec_rgy_not_implemented in DCE 1.1.
(Pointer to) a string of characters.
This is an optional parameter. It specifies (a pointer to) an application
service ticket request which consists solely of the principal's name on
whose behalf this PS request is being made.
(See
(Pointer to) information relevant to an optional application service
ticket response. This information is in the form of a structure
consisting of a status code and the ticket response.
For this version of DCE (DCE 1.1), application ticket requests are not
implemented. Upon return, this parameter is set to the value
sec_rgy_not_implemented in DCE 1.1.
See
(Pointer to) status code. See
-
-
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
The intermediary caller receives a
PS Response message from PSZ when
The parameters of
RPC binding handle, bound by the client C to a PS server PSZ.
The authentication (or key distribution) service for which
this invocation of
The authorisation service for which this invocation of
Determines the delegation type to be permitted. This is specified
by the client when it permits delegation to be enabled. Only
two types are permitted-traced delegation or
impersonation. An intermediary (server) is not permitted to
use a delegation type that was not enabled by the initiator. For
the data type definitions, see
(Pointer to) the list of delegates that are permitted. Delegate
restrictions are set by a client and limit the servers that may
act as an intermediary for the client. The restriction is imposed
by the PS when constructing a new PTGT that allows the intermediary
to operate as a delegate for the client. See
(Pointer to)
the list of targets to whom this identity may be presented.
The restrictions are placed by a given client to restrict
the set of targets to whom the client's identity may be projected.
These restrictions are imposed by the PSZ of the cell Z
(the target cell).
See
(Pointer to) the list of (application defined) optional restrictions denoting specific authorization requirements. These restrictions may be set by initiators and delegates and apply to the delegation context (they are interpreted and enforced by the target server application). A server is free to ignore any optional restriction that cannot be interpreted.
(Pointer to) the list of (application defined) required restrictions denoting specific authorization requirements. These restrictions may be set by initiators and delegates and apply to the delegation context (they are interpreted and enforced by the target server application). A server must reject requests for which there is a required restriction that cannot be interpreted.
(Pointer to)
a set of chained EPACs. This set of (one or more) EPACs is
encrypted in the same session key used to ensure the privacy
of the arguments in the RPC call, if the authenticated RPC
call is using protect level packet_privacy (more specifically,
rpc_c_protect_level_pkt_privacy, listed in
(Pointer to)
the EPAC for the intermediary that is issuing the
(Pointer to) the encrypted seal of the EPAC. It consists of an MD5 checksum over the initiator's EPAC (known as the seal of the EPAC), encrypted in the key of the Privilege Server (PSZ). This encrypted checksum is inserted into the A_D field of the EPAC in order to be passed along with the Authorization Data, in any requests (authenticated RPC calls) made subsequent to this call to other servers, as the new delegation token for this identity.
(Pointer to) PS Request message. It has length (*request).count
and value (*request).bytes[]. See
(Pointer to pointer to) PS Response message. It has length
(**response).count and value
(**response).bytes[].
See
(Pointer to)
a chain constructed from the existing (input to this function)
one with the intermediary's EPAC as an impersonator of the initiator.
As noted previously, the input delegation chain may be modified if
any EPACs in the chain have a delegate restriction preventing
this intermediary server (making this
(Pointer to) types of attributes.
Auxiliary attributes only have meaning in local requests to the PS.
This is an optional parameter which specifies instances of the types
of attributes to be searched for on the node of the principal for whom
(Pointer to) the results obtained from the search for instances of types of attributes specified in auxiliary_attribute_request. For this version of DCE (DCE 1.1), auxiliary attributes are not implemented. Upon return, this parameter is set to the value sec_rgy_not_implemented in DCE 1.1.
This is an optional parameter. It specifies (a pointer to) an application service ticket request which consists solely of the principal's name on whose behalf this PS request is being made.
(Pointer to) information relevant to an optional application service
ticket response. This information is in the form of a structure
consisting of a status code and the ticket response.
For this version of DCE (DCE 1.1), application ticket requests are not
implemented. Upon return, this parameter is set to the value
sec_rgy_not_implemented in DCE 1.1.
(Pointer to) status code. See
-
-
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
RPC binding handle, bound by the client C to a PS server PSZ.
The authentication (or key distribution) service for which
this invocation of
The authorisation service for which this invocation of
The set of privileges being requested from the PS. These privileges are usually found in one or more (encoded) extended PACs (unless the privileges being requested are not valid), for local requests. If the request is an intercell request, the PS uses the EPAC seal from the authorization data contained in the extended PTGT (EPTGT) in examining the privileges.
(Pointer to) PS Request message. It has length (*request).count
and value (*request).bytes[]. See
(Pointer to pointer to) PS Response message. It has length
(**response).count and value
(**response).bytes[].
See
An encoded EPAC set (of one or more EPACs) containing the granted privileges.
Auxiliary attributes only have meaning in local requests to the PS.
This is an optional parameter which specifies instances of the types
of attributes to be searched for on the node of the principal for whom
For this version of DCE (DCE 1.1), auxiliary attributes are not implemented. Upon return, this parameter is set to the value sec_rgy_not_implemented in DCE 1.1.
This is an optional parameter. It specifies (a pointer to) an application service ticket request which consists solely of the principal's name on whose behalf this PS request is being made.
(Pointer to) information relevant to an optional application service ticket response. This information is in the form of a structure consisting of a status code and the ticket response. For this version of DCE (DCE 1.1), application ticket requests are not implemented. Upon return, this parameter is set to the value sec_rgy_not_implemented in DCE 1.1.
(Pointer to) status code. See
-
-
} /* end running listing of rpriv interface */
Kerberos authentication (key distribution) service (as defined in
PAC-based authorisation service (as defined in this chapter).
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;
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() |
PTGS Request/PTGS Response message pair (that is, (*request).bytes[] is a value of data type PTGSRequest, and (**response).bytes[] is a value of data type PTGSResponse). This is the service by which clients acquire privilege-ticket-granting-tickets.
Thus, a PS Request message is a PTGS Request message, and a PS Response message is a PTGS Response message.
Privilege-tickets are the "same" as non-privilege-tickets (as specified in
Since privilege-tickets are special kinds of tickets, the terminology
and other specifications of
PTktA,B. This denotes a privilege-ticket nominating A in cell X, naming PSY (in cell Y; not naming A, as was the case with a non-privilege-ticket), and targeted to B in cell Y. It is either a privilege-ticket-granting-ticket (PTGT) or a privilege-service-ticket, according to whether its targeted server is or is not a KDS server. (Note that since privilege-tickets carry no transit path information, there is no notion of a "PTktA,X,Z´,···,Z´´,Y,B".)
Note that the privilege-ticket acquired via
-
-
[
uuid(47EAABA3-3000-000-0D00-01DC6C000000)
]
-
-
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:
The "definitive", "computer-friendly" identifier,
represented as a UUID, of the identity in question.
Concerning the version number of this UUID, see
An "advisory", "human-friendly" string form of the
entity's identity. It is useful for some purposes (such as performance
efficiency), but in general it is optional, in the sense that it
is the uuid (not name) field that is the definitive
identifier of the identity in question (for example, name may
even be NULL, on an implementation-specific basis).
(The definitive mapping between UUID identifiers and stringname
identifiers is given by the ID Map Facility-see
These must always have non-security-version ("version 1") UUIDs as specified in Appendix A, Universal Unique Identifier, of the referenced Open Group DCE 1.1 RPC Specification).
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.)
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
-
-
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:
The cell-relative identity of the entity being identified.
The (foreign) cell of the entity being identified.
-
-
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:
The (foreign) cell of the entity being identified.
The number of local groups (local_groups) associated with this groupset.
The non-primary local group authorisation identities associated with this groupset.
-
-
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
PAC format version 1.
-
-
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 format of this PAC.
The only currently supported PAC format is version 1
(sec_id_pac_format_v1).
Boolean value, indicating whether (true) or not (false) this
PAC is secure, in the sense of having
been authenticated by the DCE TCB (more specifically, the PS in the
server's cell);
if not authenticated, the PAC is said to be unauthenticated or
asserted (as in the phrase "this PAC's authorisation data is
merely asserted to be legitimate by the client, but not
trustworthily so; that is, not certified to be legitimate by the
(server's) PS"). Servers may grant unauthenticated accesses if they
so desire, depending on their policy (see the UNAUTHENTICATED ACLE in
Identifier of the cell relative to which the principal and group entries of this PAC (below) are "local" or "foreign".
The principal authorisation identity associated with this PAC.
The primary (local) group authorisation identity associated with this PAC.
The number of local groups (local_groups) associated with this PAC.
The number of foreign groups (foreign_groups) associated with this PAC.
The non-primary local group authorisation identities associated with this PAC.
The foreign group authorisation identities associated with this PAC.
The significance of the principal and group attributes (authorisation
identities) in the PAC is that servers use them for access authorisation
purposes (see
As mentioned in
-
-
PrivilegeTicket ::= Ticket
Its semantics are identical with that of Ticket's, with the following three supplementary semantics:
-
-
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.)
-
-
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).
-
-
PTGSRequest ::= TGSRequest
Its semantics are that it indicates a request for a
privilege-ticket-granting-ticket.
-
-
PTGSResponse ::= TGSResponse
Its semantics are that it indicates a returned privilege-ticket-granting-ticket.
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 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;
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;
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;
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
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;
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;
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;
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;
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;
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;
The sec_cred_cursor_t provides
an input or output cursor that can be used to iterate through a set
of delegates via the
-
-
typedef void *sec_cred_cursor_t;
sec_cred_attr_cursor_t provides
an input or output cursor used to iterate through a set of extended
attributes using calls to
-
-
typedef void *sec_cred_attr_cursor_t;
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.
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.
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;
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 */
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 */
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";
The Anonymous Principal UUID's octet number 6 (starting from 0), being X'11' has most significant bits 1-3 being (0) and most significant bit 4 being (1), and likewise, the Anonymous Group UUID's octet number 6, being X'11' also has most significant bits 1-3 being (0) and most significant bit 4 being (1). The same is true for the Anonymous Cell.
Thus, the Anonymous Principal UUID's octet number 8 (starting from 0), being X'b7' has most significant bits 1 and 2 being (1) and (0), respectively; and likewise, the Anonymous Group UUID's octet number 8, being X'97' also has most significant bits 1 and 2 being (1) and (0), respectively. Similarly, the Anonymous Cell UUID's octet number 8, being X'ab' also has most significant bits 1 and 2 being (1) and (0), respectively.
-
-
} /* End of sec_cred interface */
A delegation token consists of an expiration date and a byte stream.
See
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.
Its fields have the following properties:
In addition, if the low-order bit of byte 1, flags1, is set (to 1) the MD5 message digest is followed by an 8 byte DES key and an 8 byte initialization vector that is used for encrypting confidential byes of ERAs in EPACs.
The ciphertext portion is encrypted using sec_etype_des_cbc_crc.
This is the definition of the confidential bytes for the Version 0
delegation token:
-
-
const unsigned8 sec_dlg_token_v0_conf_bytes = 0x1;
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:
A 4 byte expiration timestamp in big-endian byte order, in cleartext.
A byte stream. The first 4 bytes are in cleartext and the rest are in ciphertext. The cyphertext portion of a version 0 token consists of a 4 byte timestamp in big-endian byte order followed by a 16 byte MD5 digest or checksum. In addition, if hte low-order bit of byte1 (glags1 field) is set (to 1), the MD5 message digest is followed by an 8 byte DES key and an 8 byte initialization vector that is used for encrypting confidential bytes of ERAs (extended registry attributes) in EPACs.
The ciphertext portion is encrypted using sec_etype_des_cbc_crc
defined in
In order that delegation tokens not be valid forever, the expiration timestamp is part of the encrypted data (The expiration timestamp is also provided in the clear for use by clients for checking for expired tokens).
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:
The number of tokens in the delegation token set.
(Pointer to) the set of delegation tokens.
The information about principals in Z (currently, their principal identity UUIDs and group UUIDs) that PSZ puts in their PACs.
Information that PSZ uses to vet (or modulate,
or temper) PACs received in the cross-cell authorisation scenario.
This depends on cell policy, but
typically involves such activities as discarding some privilege
attributes disallowed by Z's policies. See
Information about the shape(s) of transit paths that are trusted by PSZ. (This information is used only by PSZ, not KDSZ: KDSZ knows only about the cells it is directly cross-registered with, not about the trust to be placed in transit paths having multiple links in them.)
The details of the three steps of the success case are specified next.
(For the failure case, see
Throughout the description of PTGS request/response processing, there are two essentially different cases to be considered:
The server cell (ptgsReq.req-Body.req-ServerCell) is set to the cell name of the target server PSY; that is, it is set to Y's cell name.
The server name (ptgsReq.req-Body.req-ServerName) is set to the
RS name of the target server PSY;
that is, it is set to dce-ptgt.
If X != Y, the authorisation data field
(ptgsReq.req-Body.req-EncryptAuthzData)
is omitted. (If it is not omitted, it will not result in an error, it
will simply be ignored by PSY, as seen in
If X = Y, the authorisation data field is used to indicate the (maximum) rights that A wants PTktA,KDSY to convey (provided A is registered in RSX to have these rights, and that PSY allows them be used in Y). That is, this field is used to implement the concept of least privilege (that is, the idea that clients should be accorded only the least set of rights necessary for them to get their job done, thereby preventing the potential misuse of "excessive" rights). Namely, if A desires that PTktA,KDSY contain the authorisation information indicated by a PAC pac (a value of data type sec_id_pac_t), A pickles pac to produce a pickled PAC ppac (a value of data type sec_id_pickled_pac_t), then creates authzData (a value of data type AuthzData, whose authzData-Type has value authzDataType-PAC and whose authzData-Value is (the underlying octet string of) ppac), then authzData is encrypted using the conversation key K^A,PSY (authnr.authnr-ConversationKey, of encryption type encType, see below) if present, otherwise using the session key KA,PSY in TktA,X,···,Y,PSY, and the authorisation data field (ptgsReq.req-Body.req-EncryptedAuthzData) is then set to the resulting encrypted value.
If the authorisation data field is omitted (in the case X = Y),
then PSY rejects the request.
All options (that is, all flag bits of
ptgsReq.req-Body.req-Flags) are unselected (and all data
connected with them, namely
ptgsReq.req-Body.req-StartTime,
ptgsReq.req-Body.req-MaxExpireTime,
ptgsReq.req-Body.req-ClientAddrs and
ptgsReq.req-Body.req-AdditionalTkts, are omitted).
(Or, if options are selected and/or their data included, they will be
ignored by PSY, as seen in
The expiration time (ptgsReq.req-Body.req-ExpireTime)
is set to ahTkt.tkt-EncryptPart.tkt-ExpireTime.
(If set to any other value, that value will be ignored by
PSY, as seen in
In the case X != Y, PSY checks that the client name from TktA,X,···,Y,PSY is that of a PS server; that is, is dce-ptgt.
PSY checks the authorisation data requested by A
(ptgsReq.req-Body.req-EncryptAuthzData) against the maximum
A is entitled to (if X = Y, this information comes from
RSX; if X != Y, it comes from
TktA,X,···,Y,PSY's authorisation
data field, tkt-EncryptPart.tkt-AuthzData).
If X = Y, the maximum rights PSY will
issue to A in PTktA,KDSY
(in PACs, in ptgsTkt.tkt-EncryptPart.tkt-AuthzData and in
ptgsResp.resp-AuthnData)
is the intersection of these two sets of authorisation data;
if X != Y, the maximum rights PSY
will issue to A is simply
TktA,X,···,Y,PSY's
tkt-EncryptPart.tkt-AuthzData
(the intersection mentioned in the case X = Y could conceivably
have been used in the case X != Y as well, but this isn't
currently done-this is for potential future study).
However (in either case, X = Y or X != Y),
PSY may further restrict A's rights, according to its
local vetting (modulating, tempering) policy, thereby issuing to A
less than the maximum set of rights it would otherwise be entitled to.
In any case (X = Y or X != Y),
the minimum rights PSY will issue to a principal
A != PSY will be non-empty
(that is, if A requests rights it is not entitled to, a failure
results and PSY issues an error).
PSY also decides, again according to local policy,
whether or not it
"vouches" for the security of this authorisation data, and indicates
this by (respectively) setting or resetting the authenticated bit of
the PAC-this allows servers to grant unauthenticated accesses if
they so desire, depending on their policy.
(For example, a PS will typically reset the authenticated bit if
it does not trust the strength of the encryption type used, or if the
transit path (below) does not conform to a trusted shape.)
The authorisation data issued to A is passed back to A in
two PACs, one in ptgsTkt.tkt-EncryptPart.tkt-AuthzData and one in
ptgsResp.resp-AuthnData, and these two PACs have identical
contents but are formatted differently: the
former is of data type AuthzData, with authzData-Type =
authzDataType-PAC and authzData-Value (the underlying
OCTET STRING of) a pickled PAC;
the latter is of data type AuthnData, with
authnData-Type = -2 (see Note below) and authnData-Value
(the underlying OCTET STRING of) the encryption of a pickled
PAC; that is, a value of data type EncryptedData, with
encData-EncType = encType,
an appropriate encData-EncKeyVersNum,
and encData-CipherText (the underlying OCTET STRING of) the
encryption of a pickled PAC using the conversation key
K^A,PSY if present, otherwise using the
session key KA,PSY.
PSY "ignores" all options (as well as data connected with them if present); that is, it treats all flag bits of ptgsReq.req-Body.req-Flags as if they were unselected. Thus, PSY unselects all flag bits of PTktA,KDSY's option field (ptgsTkt.tkt-EncryptPart.tkt-Flags).
PSY sets PTktA,KDSY's
expiration time (ptgsTkt.tkt-EncryptPart.tkt-ExpireTime) to
TktA,X,···,Y,PSY's
expiration time (ahTkt.tkt-EncryptPart.tkt-ExpireTime).
(Note that PSY ignores
ptgsReq.req-Body.req-ExpireTime.)
PSY sets PTktA,KDSY's client addresses (ptgsTkt.tkt-EncryptPart.tkt-ClientAddrs) to TktA,X,···,Y,PSY's client addresses (ahTkt.tkt-EncryptPart.tkt-ClientAddrs). (Note that PSY ignores ptgsReq.req-Body.req-ClientAddrs.)
PSY examines TktA,X,···,Y,PSY's transit path field (ahTkt.tkt-EncryptPart.tkt-TransitPath), and checks that it is a "trusted shape" (which in general depends on PSY's policy; in the special case where X = Y or X and Y are cross-registered with one another, the transit path is empty (or absent), and this is always considered to be a trusted shape)-this is also called PSY's "vetting the transit path". PSY sets PTktA,KDSY's transit path (ptgsTkt.tkt-EncryptPart.tkt-TransitPath) to the empty (or absent) path.
A learns the authorisation information (PAC) that has been issued to
it from ptgsResp.resp-AuthnData (which is encrypted as
specified in
The details of the three steps of the success case are specified next.
By specification, it is, with appropriate modification of detail,
identical to
The client name (authnr.authnr-ClientName) is set to
PSX's RS name (that is, to dce-ptgt).
The authorisation data field (authnr.authnr-AuthzData) is omitted.
The client cell from pAhTkt (pAhTkt.tkt-EncryptPart.tkt-ClientCell) is checked to be B's cell name; that is, Y's cell name.
The client name from pAhTkt (pAhTkt.tkt-EncryptPart.tkt-ClientName) is checked to be PSY's RS name; that is, dce-ptgt.
B uses the ticket authorisation data (pAhTkt.tkt-EncryptPart.tkt-AuthzData); that is, A's PAC information, to make authorisation decisions. Typically-that is, if B protects its resources via a Common ACL Manager-this will be done using the DCE Common Access Determination Algorithm.
B ignores the authenticator's authorisation data field (authnr.authnr-AuthzData).
Consider a PS Request, psReq, received by PSY
from a client A.
PSY performs the algorithm specified in
PSY examines the transit path of the incoming
service-ticket (in the
PSY removes from the incoming PAC (in the incoming service-ticket) any authorisation attributes that are prohibited by Y's policies.
These two activities have already been discussed in context above, and need have no more said about them here.
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
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).
Contents | Next section | Index |