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:
-
rpc_handle
RPC binding handle, bound by the client C to a PS server
PSZ.
-
authn_service
The authentication (or key distribution) service for which
this invocation of
ps_request_ptgt()
is requesting a PAC. The currently supported authentication services
are collected in
Registered Authentication Services
.
-
authz_service
The authorisation service for which this invocation of
ps_request_ptgt()
is requesting a privilege attribute certificate.
The currently registered authorisation services are collected in
Registered Authorisation Services
.
-
request
(Pointer to) PS Request message. It has length (*request).count
and value (*request).bytes[]. See
PTGS Requests
.
-
response
(Pointer to pointer to) PS Response message. It has length
(**response).count and value
(**response).bytes[].
See
PTGS Responses
and
PS Errors
.
-
status
(Pointer to) status code. See
Status Codes
.
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:
-
rpc_handle
RPC binding handle, bound by the client C to a PS server
PSZ.
-
authn_service
The authentication (or key distribution) service for which
this invocation of
ps_request_become_delegate()
is requesting an EPAC. The currently supported authentication services are
collected in
Registered Authentication Services
.
-
authz_service
The authorisation service for which this invocation of
ps_request_become_delegate()
is requesting a privilege attribute certificate.
The currently registered authorisation services are collected in
Registered Authorisation Services
.
-
delegation_type_permitted
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
Supported Delegation Types
.
-
delegate_restrictions
(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
Delegate and Target Restriction Types
.
For definitions of the entries for the restrictions, see
Entry Types for Delegate and Target Restrictions
.
-
target_restrictions
(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
Delegate and Target Restriction Types
.
For definitions of the entries for the restrictions, see
Entry Types for Delegate and Target Restrictions
.
-
optional_restrictions
(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
Optional and Required Restrictions
for the data type definition.
-
required_restrictions
(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
Optional and Required Restrictions
for the data type definition.
-
compatibility_mode
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
Delegation Compatibility Modes
for a description of the values and
The Extended PAC (EPAC)
for a description of the DCE 1.1 A_D field in the PTGT.
-
delegation_chain
(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
Protected RPC
).
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.
-
delegate
(Pointer to)
the EPAC for the intermediary that is issuing the
ps_request_become_delegate().
-
delegation_token
(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.
-
request
(Pointer to) PS Request message. It has length (*request).count
and value (*request).bytes[]. See
PTGS Requests
.
-
response
(Pointer to pointer to) PS Response message. It has length
(**response).count and value
(**response).bytes[].
See
PTGS Responses
and
PS Errors
.
-
new_delegation_chain
(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
ps_request_become_delegate()
request) from transmitting their identity. In such instances,
each such EPAC will be replaced by an anonymous EPAC. See
Anonymous Identity
for more details.
-
auxiliary_attribute_request
(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
ps_request_become_delegate()
is granted.
- Note:
- This parameter is not implemented in this version of DCE (DCE 1.1).
-
auxiliary_attribute_result
(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.
-
application_ticket_request
(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
Principal Names
).
-
application_ticket_result
(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
ps_app_tkt_result_t
.
-
status
(Pointer to) status code. See
Status Codes
.
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:
-
rpc_handle
RPC binding handle, bound by the client C to a PS server
PSZ.
-
authn_service
The authentication (or key distribution) service for which
this invocation of
ps_request_become_impersonator()
is requesting an EPAC. The currently supported authentication services are
collected in
Registered Authentication Services
.
-
authz_service
The authorisation service for which this invocation of
ps_request_become_impersonator()
is requesting a privilege attribute certificate.
The currently registered authorisation services are collected in
Registered Authorisation Services
.
-
delegation_type_permitted
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
Supported Delegation Types
.
-
delegate_restrictions
(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
Delegate and Target Restriction Types
.
-
target_restrictions
(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
Delegate and Target Restriction Types
.
-
optional_restrictions
(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.
-
required_restrictions
(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.
-
delegation_chain
(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
Protected RPC
).
-
impersonator
(Pointer to)
the EPAC for the intermediary that is issuing the
ps_request_become_impersonator().
-
delegation_token
(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.
-
request
(Pointer to) PS Request message. It has length (*request).count
and value (*request).bytes[]. See
PTGS Requests
.
-
response
(Pointer to pointer to) PS Response message. It has length
(**response).count and value
(**response).bytes[].
See
PTGS Responses
and
PS Errors
.
-
new_delegation_chain
(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
ps_request_become_impersonator()
request) from transmitting their identity. In such instances,
each such EPAC will be replaced by an anonymous EPAC. See
Anonymous Identity
for more details.
-
auxiliary_attribute_request
(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
ps_request_become_impersonator()
is granted.
- Note:
- This parameter is not implemented in this version of DCE (DCE 1.1).
-
auxiliary_attribute_result
(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.
-
application_ticket_request
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.
-
application_ticket_result
(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.
-
status
(Pointer to) status code. See
Status Codes
.
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:
-
rpc_handle
RPC binding handle, bound by the client C to a PS server
PSZ.
-
authn_service
The authentication (or key distribution) service for which
this invocation of
ps_request_eptgt()
is requesting an EPAC. The currently supported authentication services are
collected in
Registered Authentication Services
.
-
authz_service
The authorisation service for which this invocation of
ps_request_eptgt()
is requesting a privilege attribute certificate.
The currently registered authorisation services are collected in
Registered Authorisation Services
.
-
requested_privileges
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.
-
request
(Pointer to) PS Request message. It has length (*request).count
and value (*request).bytes[]. See
PTGS Requests
.
-
response
(Pointer to pointer to) PS Response message. It has length
(**response).count and value
(**response).bytes[].
See
PTGS Responses
and
PS Errors
.
-
granted_privileges
An encoded EPAC set (of one or more EPACs) containing the
granted privileges.
-
auxiliary_attribute_request
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
ps_request_eptgt()
is granted.
- Note:
- This parameter is not implemented in this version of DCE (DCE 1.1).
-
auxiliary_attribute_result
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.
-
application_ticket_request
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.
-
application_ticket_result
(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.
-
status
(Pointer to) status code. See
Status Codes
.
-
-
} /* 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
):
-
Privilege-ticket-granting Service (PTGS)
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
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
):
-
The client "named" in a privilege-ticket is always a PS server, never
a non-PS client principal.
-
The authorisation data in a privilege-ticket carries PAC information (see
Registered Authorisation Data Types
,
Privilege Attribute Certificates (PACs)
and
Pickled PACs
)
pertaining to some client. That client is said to be the client
nominated by the privilege-ticket (unless the PAC information is
empty, in which case the nominated client defaults to the named client;
that is, to the PS server mentioned in the preceding item).
-
The transit path carried by a privilege-ticket is always empty (or absent).
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):
-
Privilege-ticket
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
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:
-
uuid
The "definitive", "computer-friendly" identifier,
represented as a UUID, of the identity in question.
Concerning the version number of this UUID, see
Security-Version (Version 2) UUIDs
.
-
name
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
ID Map Facility
and
ID Map Facility RPC Interface
.)
- 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:
-
The version number is 2.
-
The clock_seq_low field (which represents an integer in the range
[0, 28-1]) is interpreted as a local domain
(as represented by sec_rgy_domain_t; see
sec_rgy_domain_t
);
that is, an identifier domain meaningful to the local host.
(Note that the data type sec_rgy_domain_t can potentially hold
values outside the range [0, 28-1]; however, the only
values currently registered are in the range [0, 2], so this type
mismatch is not significant.) In the
particular case of a POSIX host, the value sec_rgy_domain_person is
to be interpreted as the "POSIX UID domain", and the value
sec_rgy_domain_group is to be interpreted as the "POSIX GID domain".
-
The time_low field (which represents an integer in the range
[0, 232-1]) is interpreted as a local-ID;
that is, an identifier (within the domain specified by clock_seq_low)
meaningful to the local host. In the particular case of a POSIX host,
when combined with a POSIX UID or POSIX GID domain in the
clock_seq_low field (above), the time_low field
represents a POSIX UID or POSIX GID, respectively.
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:
-
cell
The (foreign) cell of the entity being identified.
-
count_local_groups
The number of local groups (local_groups) associated with this groupset.
-
local_groups
The non-primary local group authorisation identities
associated with this groupset.
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:
-
sec_id_pac_format_v1 = 0
PAC format version 1.
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:
-
pac_format
The format of this PAC.
The only currently supported PAC format is version 1
(sec_id_pac_format_v1).
-
authenticated
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
ACLE Types
,
and its use in the Common Access Determination Algorithm in
Common Access Determination Algorithm
).
-
cell
Identifier of the cell relative to which the principal and group entries
of this PAC (below) are "local" or "foreign".
-
principal
The principal authorisation identity associated with this PAC.
-
primary_group
The primary (local) group authorisation identity associated with this PAC.
-
count_local_groups
The number of local groups (local_groups) associated with this PAC.
-
count_foreign_groups
The number of foreign groups (foreign_groups) associated with this PAC.
-
local_groups
The non-primary local group authorisation identities
associated with this PAC.
-
foreign_groups
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
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:
-
The named client in a privilege-ticket is always a privilege server
(that is, tkt-EncryptPart.tkt-ClientName is always dce-ptgt).
-
The authorisation data field (tkt-EncryptPart.tkt-AuthzData)
in a privilege-ticket carries an array of authorisation data, say
authzData (data type AuthzData, see
Authorisation Data
),
which contains one and only one element, say authzData[i], whose
type (authzData[i].authzData-Type) is equal to
authzDataType-PAC; that element's value
(authzData[i].authzData-Value)
must be (the underlying OCTET STRING of) a pickled PAC, as defined in
Pickled PACs
.
The client nominated by the privilege-ticket is the
principal identified by the underlying PAC.
- Notes:
-
The case of an "empty PAC" (that is, the pickled_data[] array of the
pickled PAC has length zero) is not currently supported, but is reserved for
potential future usage. (It may, for example, be useful in supporting
"anonymous clients".)
-
As seen in
PS Server Receives PTGS Request and Sends PTGS Response
,
if the PS in a cell ever
issued to a principal A != PS in its own cell a PTGS Response
containing a PTGT having an empty authorisation data array, a
clear breach of security would result. For, such a
PTGT would be indistinguishable from a TGT identifying the PS itself as
the named client. Therefore, A could then use this PTGT in
a TGS Request, requesting that arbitrary authorisation data
(PAC) of A's choosing be included in the resulting
privilege-service-ticket (see
KDS Server Receives TGS Request and Sends TGS Response
).
In this manner, A could illicitly impersonate any principal it desired.
-
The transit path (tkt-EncryptPart.tkt-TransitPath) is always empty
(or absent). In particular, servers targeted by privilege-tickets cannot
use the privilege-ticket to
distinguish remote service requests (that is, from clients in remote
cells) from local service requests (that is, from clients in the
server's local cell).
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:
-
The associated ticket (authnHdr-Tkt) is a privilege-ticket, not
a non-privilege-ticket.
Hence, a privilege authentication header supplies forward
authorisation information (a PAC)-not really authentication
information (at least, not in the sense of a stringname)-
that "authorises a client A to a server B". (Whether or not
B actually grants A its request for service depends upon a
conceptually separate access determination step.)
(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 time_hi_and_version field contains the version
number (1) in the 4 most significant bits.
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.
-
The variant field consists of a variable number of msbs (most
significant bits) of the
clock_seq_hi_and_reserved field. This field determines the
layout of the UUID. For the DCE variant, most significant bits
1 and 2 are defined as being the values (1) and (0), respectively.
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.
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:
-
The first 4 fields (0 through 3, inclusive) are in cleartext.
-
The remaining fields (4 through 52, inclusive) are in ciphertext.
-
The first 8 fields are required; the remaining 2 are optional.
-
Field 4 (key version number) is the current version of the Privilege
Server key used to encrypt the ciphertext portion of the token bytes.
-
The ciphertext portion of a version 0 token consists of a 4 byte
expiration timestamp in big-endian byte order followed by a 16 byte
MD5 message digest (or checksum).
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.
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:
-
expiration
A 4 byte expiration timestamp in big-endian byte order, in cleartext.
-
token_bytes
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
sec_etype_t
.
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).
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:
-
Authorisation (PAC) attributes
The information about principals in Z (currently, their principal
identity UUIDs and group UUIDs) that PSZ puts in their PACs.
-
PAC vetting rules
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
Cross-cell Authorisation-Vetting the Privilege-ticket-granting-ticket
.
-
Transit path vetting rules
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 simplest (and most secure) trusted shape model is the
self model, in which the only transit paths that are trusted are
those of length 0; that is, no cross-cell links are trusted.
The next most simple (and next most secure) is the peer-to-peer
model, in which a transit path is trusted if and only if it has length
(0 or) 1; that is, only a cell's directly cross-registered peers are
trusted (in addition to itself).
Another simple (but rather insecure) model is the universal trust
model, in which every transit path is trusted.
A rather sophisticated (and rather secure) model is the up-over-down
model, which makes use of the natural hierarchical structure of cell
names: the trusted transit paths are those which include ancestors (in
the namespace sense) of the client's and server's cells, up to a common
ancestor or (at most one) non-ancestral peer-to-peer link (see
Multi-Hop Trust Chains
).
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:
-
A client prepares a PTGS Request and sends it to a PS server.
-
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.
-
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:
-
The client is in the same cell as the PS server.
In this case, the client sends the PS server a
PAC containing the authorisation data it wants to be
included in the privilege-ticket-granting-ticket, and the
PS server checks this requested data against
the authorisation information registered for the client in the RS
datastore before it issues the client a privilege-ticket-granting-ticket
with the requested
authorisation data (minus that not registered for the client) in it
(informing the client at the same time of the contents of the issued PAC).
-
The client is in a different cell from the PS server. In this case, the
client sends the PS server a PAC, and the PS server vets the transit path
taken by the client's request (that is, evaluates the transit path for a
"trusted shape"), and vets (modulates, tempers) the PAC itself for use in
its cell.
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.
-
Server cell
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.
-
Server 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.
- Note:
- As discussed in
Introduction to Security Services
,
the DCE RPC programming
model handles communications with the PS in runtime code (just as it
deals with, for example, cross-cell referrals), so that the application
programmer does not have to deal with it directly.
-
Authorisation data
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
PS Server Receives PTGS Request and Sends PTGS Response
.)
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.
- Note:
- A client A that wants to receive a PAC entitling it to
the absolute maximum rights it is entitled to, can do so by first
querying RSX to determine what its maximum rights are
-see
rs_acct_get_projlist(),
rs_acct_get_projlist()
.)
-
Options
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
PS Server Receives PTGS Request and Sends PTGS Response
.)
-
Expiration time
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
PS Server Receives PTGS Request and Sends PTGS Response
.)
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 name
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.
-
Authorisation data
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.
- Note:
-
If the value authnData-Type = -2 were being used in a
Kerberos authentication protocol, it would be "unregisterable" in
the sense of
Authentication Data
(because it is negative).
However, this value is being used here not in that
way, but in an authorisation protocol.
-
Options
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).
-
Expiration time
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.)
-
Client addresses
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.)
-
Transit path
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.
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:
-
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.
-
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.
-
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.
-
Client name
The client name (authnr.authnr-ClientName) is set to
PSX's RS name (that is, to dce-ptgt).
-
Authorisation data
The authorisation data field (authnr.authnr-AuthzData) is omitted.
- 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 cell
The client cell from pAhTkt
(pAhTkt.tkt-EncryptPart.tkt-ClientCell) is checked to be
B's cell name; that is, Y's cell name.
-
Client name
The client name from pAhTkt
(pAhTkt.tkt-EncryptPart.tkt-ClientName) is checked to be
PSY's RS name; that is, dce-ptgt.
-
Ticket authorisation data
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.
-
Authenticator authorisation data
B ignores the authenticator's authorisation data field
(authnr.authnr-AuthzData).
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:
-
Vetting (or evaluating) the transit path
PSY examines the transit path of the incoming
service-ticket (in the
ps_request_*())
to verify that it conforms to a "trusted shape" (depending on Y's
policies).
-
Vetting (or modulating, tempering) the PAC
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.
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:
-
B must vet the transit path (using criteria of its own devising).
-
B must be prepared to grant or deny access solely on the basis of
the individual identity of A (because that's all that is projected
to B-no "name-based group identities" are projected or
supported).
-
B must support its own facilities providing the functionality of the
ACLs defined elsewhere in DCE (such as "name-based permissions",
"name-based access control managers", "name-based access control
editors" and "name-based common access determination algorithm").
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.