Security

This chapter defines the RPC security services that an RPC application may select and describes how they are supported in the basic RPC protocol and mapped to the underlying security services. The Generic RPC Security Model describes security semantics and generic security encodings that are provided by RPC for both the connection-oriented and connectionless RPC protocols. Security Services for Connection-oriented Protocol and Security Services for Connectionless Protocol specify encodings for the connectionless and connection-oriented RPC protocols, respectively, for the DCE secret key authentication protocol. The encodings specified in Security Services for Connection-oriented Protocol and Security Services for Connectionless Protocol are not generally applicable to other security protocols.

In addition to the encodings and semantics specified in this chapter, the RPC run-time protocol machines specified in RPC Protocol Definitions to Connection-oriented RPC Protocol Machines indicate how security-related processing is integrated with protocol processing. The mechanisms by which the underlying security services enforce protection guarantees (for example, encryption algorithms or cryptographic key management) are outside the scope of the RPC specification. The DCE: Security Services specification defines these protocols, algorithms, other security-related processing, and the contents of the messages used by the underlying security services to support RPC.

The DCE Security Model offers a number of optional services above the basic RPC. It offers a variety of levels of security service quality. These are realised via a combination of authentication, data protection and authorisation mechanisms.

The specified models allow DCE users to invoke cryptographically secured mutual authentication of a client and server, and to pass certified authorisation data from client to server as part of the RPC invocation. The server can then discover the client's identity and authorisation credentials, and determine what access to authorise. RPC security services also provide protection against undetected modifications of call data, cryptographic privacy of data, and protection against replay of calls and data.

The RPC run-time system has two roles in this. First, it is the conduit for exchanging the security credentials between clients and servers. Second, it may protect its communications from various security threats.

The Generic RPC Security Model

The generic RPC security model and encodings specified in the following sections assume support for, but are not limited to, the ISO C standard Security Service. They may be applied to alternate security services as well. The model and encodings apply to both the connectionless and connection-oriented RPC protocols.

Generic Operation

When an RPC is initiated with a request for security services, the service provider determines if a pairwise security context has already been established between the client and server principals. This security context might include a shared session key, sequence numbers, verification state, and so on. If this context has not been established yet for that client/server principal pair, or has expired, the client RPC service provider requests initiating credentials from the security services. If these credentials are successfully acquired, the client RPC service provider then incorporates them into the initial request. The credentials may be exchanged only on call boundaries.

The server processes these security data and then responds with its own security data. If this exchange is successful, both the client and the server have established and synchronised their initial security information. Depending on the level of service requested, this may provide strong cryptographically-based mutual authentication.

For the actual call PDUs, for control PDUs and for subsequent calls, the selected protection services are provided. For example, if strong integrity protection is required, each PDU is cryptographically protected against undetected modification and deletion by the transmitter and verified by the receiver. Or, if privacy protection is specified, stub data for request and response PDUs is encrypted and integrity protected. If a mismatch is found, an error message is generated, which is encoded in a fault, alter_context_response or bind_nak PDU for the connection-oriented protocol or a reject PDU for the connectionless protocol, as detailed in Connectionless RPC Protocol Machines and Connection-oriented RPC Protocol Machines .

Note:

The level of service cannot be changed for an already established security context.

A client that represents multiple user principals has the option of providing security services such that each principal is individually authenticated. When a security context is established, a requesting client principal is authenticated. An application may obtain the security credentials for additional client principals, and then cause additional mutual authentications to occur by requesting security services on behalf of the additional principals.

For each principal, the RPC protocols exchange the credentials in one of three ways:

• by performing the conversation manager exchange for authenticated calls (connectionless protocol)

• by performing the alter_context exchange on the existing association (connection-oriented protocol)

• by creating a new association with the bind exchange (connection-oriented protocol).

The server may allow for a grace period of service after credentials expire to compensate for processing and communications delays. The client avoids sending requests it knows are likely to expire. To force a re-authentication, it fetches new credentials for use with the server from the security service and establishes the new security context according to the underlying protocol.

The RPC run-time system determines the security services used when accessing name services on behalf of a principal. Connection-oriented PDU Data Types describes how RPC uses name services. If the credentials of the principal are available to the RPC run-time system, then mutual authentication, based on these credentials, is used for name service accesses. If the security context of the principal is not available to the RPC run-time system, then name service accesses are unauthenticated. It is important to note that there is a difference between the security context being unavailable and the security context having expired or being otherwise invalid. An expired or invalid context results in authentication failure.

Generic Encodings

Connection-oriented and connectionless PDUs may contain an optional authentication verifier. Authentication verifier encodings are largely dependent on the authentication protocol in use as detailed in the DCE: Security Services specification. The following sections specify those encodings that are authentication protocol-independent.

Protection Levels

RPC implementations are not required to support all of the protection levels specified here, but supported protection levels must have at least this level of protection for all protocols.

Authentication verifiers encode protection levels as a single byte. The defined protection levels are as follows:

dce_c_authn_level_none=1

The client has requested that no protection be performed. Depending on server policy, the client may be granted access as an unauthenticated principal.

dce_c_authn_level_connect=2

The client and server identities are exchanged and cryptographically verified. Strong mutual authentication is achieved-per association for the connection-oriented protocol and per activity for the connectionless protocol-and is protected against replays. However, this level provides no protection services per PDU.

dce_c_authn_level_call=3

This level offers the dce_c_authn_level_connect services plus integrity protection of the first fragment only of each call. For the connection-oriented protocol any request for this level is automatically upgraded to dce_c_authn_level_pkt.

dce_c_authn_level_pkt=4

This level offers the dce_c_authn_level_connect services plus per-PDU replay and misordering detection. It provides no per-PDU modification protection.

dce_c_authn_level_pkt_integrity=5

This level offers the dce_c_authn_level_pkt services plus per-PDU modification and deletion detection.

dce_c_authn_level_pkt_privacy=6

This level offers the dce_c_authn_level_pkt_integrity services plus privacy (encryption) of stub call arguments only. All run-time and lower-layer headers are still transmitted in clear text.

These values map directly to the values specified in Authentication, Authorisation and Protection-level Arguments for the protect_level argument to the RPC API routines. The protect_level value rpc_c_protect_level_level specifies the same protection level as the one specified by the PDU value dce_c_authn_level_level.

Authentication Services

Authentication services are identified by a single byte. In connectionless PDUs, this is encoded in the PDU header field auth_proto. In connection-oriented PDUs, this is encoded in the authentication verifier. The currently supported values are as follows:

• dce_c_rpc_authn_protocol_none=0

• dce_c_rpc_authn_protocol_krb5=1

These values map directly to the values specified in Authentication, Authorisation and Protection-level Arguments for the authn_svc argument to the RPC API routines. The value dce_c_rpc_authn_protocol_none maps to rpc_c_authn_none, and the value dce_c_rpc_authn_protocol_krb5 maps to rpc_c_authn_dce_secret.

The cryptographic protocols and algorithms to which these identifiers map are defined by the DCE: Security Services specification.

Authorisation Services

Authorisation services are identified by a single byte. In the connection-oriented protocol, this is encoded in the authentication verifier. In the connectionless protocol, this is part of the data of the conversation manager challenge and response.

Two authorisation models are supported. These are encoded with the following values:

• dce_c_authz_name=1

• dce_c_authz_dce=2

These values map directly to the values specified in Authentication, Authorisation and Protection-level Arguments for the authz_svc argument to the RPC API routines.

The authorisation service dce_c_authz_name asserts, without cryptographic protection, the principal name for level dce_c_authn_level_none and authenticates the principal name for other levels. The authorisation service dce_c_authz_dce asserts the principal name and authorisation data, without cryptographic protection, for level dce_c_authn_level_none and authenticates the principal and its authorisation data for other levels. The DCE: Security Services specification specifies the guarantees provided by these authorisation models.

Underlying Security Services Required

To support RPC security, underlying security services called by RPC must provide:

• Integrity protection of data composed of an arbitrary number of octets. The integrity protection for some RPC levels of service require that the underlying security services compute and return a value which will be referred to as a "checksum".

• Privacy protection of data composed of an arbitrary number of octets. The privacy protection for some RPC levels of service require that the underlying security services compute and return privacy protected data.

• Creation and verification of secure authentication and authorisation credentials.

• Indication as to whether an existing security context can be used for an RPC.

The methods by which these services are instantiated are defined by the DCE: Security Services specification. Algorithms not defined by the DCE: Security Services specification may be used instead to provide these services with loss of universal interoperability.

Note:

In subsequent sections, references are made to the invocation of these services. The data passed to these services for privacy or integrity protection, or both, must have been encoded in the transfer syntax to be used in RPC PDUs. For example, when using NDR encoding, the protection operations are carried out on the sender's representation of the data.

Security Services for Connection-oriented Protocol

The following sections specify security semantics and encodings for connection-oriented RPC protocol when the PDU header field auth_length is non-zero and the field auth_type of the authentication verifier is dce_c_rpc_authn_protocol_krb5. Use of other protection services is permitted but is outside the scope of this specification and will reduce interoperability.

Client Association State Machine

Whenever a client attempts to create a new association to a server, it must take the following steps:

1. Create a new association UUID, assoc_uuid.

2. Invoke the security services to compute a non-cryptographic checksum of the assoc_uuid. The value computed will be denoted as assoc_uuid_chksum. The algorithm for computing this non-cryptographic checksum is specified in the DCE: Security Services specification.

3. Initialise two 32-bit state variables called sequence numbers which may assume only integral values in the range 0 to 2³²-1 inclusive:

   • u_int32 next_send_seq=0

   • u_int32 next_recv_seq=0

These steps are required even if there are already other associations established and authenticated for the client/server pair. Each new association request must establish pairwise credentials between the client and server even if they have already been established for the same client/server pair on a different association.

While establishing security credentials, the client provider may transmit a bind PDU to establish the initial security context, or an alter_context PDU to alter or add new security contexts. It may receive bind_ack, bind_nak or alter_context_resp PDUs.

Server Association State Machine

Whenever a server receives a new association request, it must take the following steps:

1. Store the received value assoc_uuid_chksum.

2. Initialise two 32-bit state variables called sequence numbers which may assume only integral values in the range 0 to 2³²-1 inclusive:

   • u_int32 next_send_seq=0

   • u_int32 next_recv_seq=1

While establishing security credentials, the server provider may receive bind or alter_context PDUs, and transmit bind_ack, bind_nak or alter_context_resp PDUs.

Sequence Numbers

While sequence numbers are not transmitted explicitly by the RPC protocol, they are used in the computation of various security checks for the PDUs. Sequence numbers are initialised to 0 (zero) on the establishment of each association and used by all PDUs even when no security services have been requested. Every PDU transmitted, including call fragment PDUs, is assigned the value of next_send_seq, which is then atomically incremented. Implementations must ensure that PDUs are transmitted in the same order that the sequence numbers are assigned. Receivers must check the anticipated next_recv_seq value against the received PDUs, and then atomically increment next_recv_seq. Any out-of-order PDUs generate an invalid_checksum reject status code, which is transmitted in the fault, bind_ack and alter_context_response PDUs. Implementations must take care to verify the received PDU sequence numbers in the same order the PDUs are received.

The most significant bit of the sequence number is used as a direction indicator. When requesting security services using the sequence numbers assigned to PDUs sent from the server to the client, RPC must invert the most significant bit of the sequence number before passing the value to the underlying security services. Both client and server RPC run-time systems must perform this inversion for security processing of PDUs sent from server to client.

There is no provision for overflow of sequence numbers. The maximum value is 2³²-1.

The auth_context_id Field

The auth_context_id field is an unprotected hint that is transmitted to suggest the appropriate security context for the receiver to use. It may be used to distinguish among multiple user principals sharing the same client. This is typically a table index or pointer value that must be unique at least across the scope and lifetime of an association group.

Integrity Protection

The integrity checksums required for some of the levels of service may be computed via different algorithms. The algorithm used to protect a specific PDU is indicated by the value of the sub_type field, which encodes the authentication service using one of the values given in Authentication Services , and the desired protection level.

For all variants of the checksum, the transmitting side must pass to the underlying security services:

• the security context indicated by the current auth_context_id

• the assoc_uuid_chksum

• the desired protection level

• the identification of the checksum algorithm to be used (corresponding to the value to be sent in the sub_type field)

• the sequence number (next_send_seq)

• the PDU without the authentication verifier.

The computed checksum and checksum length are then inserted into their respective authentication verifier fields.

The receiving side recomputes the checksum, by invoking the underlying security services and passing (as needed):

• the security context for the call (hinted at by the auth_context_id in the authentication verifier)

• the previously received assoc_uuid_chksum

• the desired protection level

• the identification of the checksum algorithm to be used (corresponding to the value to be received in the sub_type field)

• the local receive sequence number, next_recv_seq

• the received PDU without the authentication verifier.

The receiver then compares the computed checksum to the value received in the verifier. If they are identical, then the PDU is accepted as authentic.

If the receiver does not support the sub_type specified by the transmitter, an error indicating invalid checksum is returned. The callee should respond with the same subtype requested by the caller.

Connection-oriented Encodings

Most of the connection-oriented RPC PDUs, as defined in RPC PDU Encodings , may include an optional authentication verifier that contains authentication and/or authorisation data. The verifier is present if and only if the auth_length field in the PDU is non-zero. The verifier consists of a set of common fields and one field, auth_value, the encoding of which depends on authentication service, authorisation service, protection level and PDU type. The length of the authentication verifier varies depending on the data encoded by the auth_value field.

Common Authentication Verifier Encodings

The common authentication verifier is defined as the following structure:

 

typedef struct{

        /* restore 4 byte alignment */

        u_int8  [size_is(auth_pad_length)] auth_pad[]; /* align(4) */
        u_int8  auth_type;       /* :01  which authent service */
        u_int8  auth_level;      /* :01  which level within service */
        u_int8  auth_pad_length; /* :01 */
        u_int8  auth_reserved;   /* :01 reserved, m.b.z. */
        u_int32 auth_context_id; /* :04 */
        u_int8  [size_is(auth_length)] auth_value[]; /* credentials */

} auth_verifier_co_t;

The auth_pad field is required to restore 0 mod 4 alignment following the stub data, if any. It consists of 0, 1, 2 or 3 null bytes.

The auth_type field defines which authentication service is in use. Currently supported values are specified in Authentication Services .

The auth_level field defines the protection level. The supported values are specified in Protection Levels .

The auth_pad_length field indicates the number of pad bytes that are appended to the header and stub data before the authentication verifier.

The auth_reserved field is reserved for future use. It must be 0 (zero) on transmission, and it is ignored on reception.

The auth_context_id field indicates the corresponding security context previously established.

The auth_value field may contain a variety of security-related data. For the bind, bind_ack, alter_context and alter_context_response PDUs, this field encodes credentials. For other PDUs, this field holds checksums and other per-PDU security data that depend on the protection level. Encodings of this field depend on the PDU type, authentication service, authorisation service and protection level. Encoding for Per-PDU Services specifies the encodings of this field for per-PDU security services. Credentials Encoding specifies the connection-oriented encodings for exchanging credentials.

Encoding for Per-PDU Services

Authentication verifiers contain an auth_value field that holds checksums, credentials and other security-related data. When used for per-PDU security services, the auth_value encoding depends on the protection level. The following sections define the encodings of the auth_value field to provide per-PDU security services. For protection level dce_c_authn_level_pkt_privacy, the encryption of the PDU body data is also specified.

The encodings are modelled as IDL structure definitions. As in the RPC PDU definitions, they assume no padding between elements, and they assume NDR transfer syntax.

The sub_type fields in auth_value encodings allow variant algorithms for providing the same level of services. This field can also be used to indicate that an invalid checksum was received. The currently defined values are as follows:

• dce_c_cn_dce_sub_type=0

• dce_c_cn_dce_sub_type_md5=1

• dce_c_cn_dce_sub_type_invalid_checksum=2 (Invalid integrity)

The mapping from the values dce_c_cn_dce_sub_type and dce_c_cn_dce_sub_type_md5 to specific algorithms is defined by the DCE: Security Services specification. The value dce_c_cn_dce_sub_type_invalid_checksum is used to indicate that an invalid checksum was detected.

The following sections specify auth_value encodings for each protection level.

The dce_c_authn_level_none Protection Level

The auth_value is null; the entire authentication verifier may be omitted.

The dce_c_authn_level_connect Protection Level

The auth_value encoding is as follows:

 

typedef struct{
            u_int8      sub_type;
            } auth_value_t;

The dce_c_authn_level_call Protection Level

This level is not supported as a separate entity. Instead, requests for this level will automatically be upgraded to dce_c_authn_level_pkt.

The dce_c_authn_level_pkt Protection Level

The auth_value encoding is as follows:

 

typedef struct{
            u_int8      sub_type;
            u_int8      checksum_length;
            byte        [size_is(checksum_length)] checksum[];
            } auth_value_t;

where the field "checksum" is the checksum value returned by the underlying security service in response to an integrity protection call (see Generic Operation ).

The dce_c_authn_level_pkt_integrity Protection Level

The auth_value encoding is as follows:

 

typedef struct{
            u_int8      sub_type;
            u_int8      checksum_length;
            byte        [size_is(checksum_length)] checksum[];
            } auth_value_t;

where the field "checksum" is the checksum value returned by the underlying security service in response to an integrity protection call (see Generic Operation ).

The dce_c_authn_level_pkt_privacy Protection Level

In contrast to the other security levels, this level also requires changes to the contents of the body data of the standard RPC PDUs. This level of service provides strong integrity protection for the entire PDU, plus privacy protection for the body data only. Therefore, only the bodies of the request, response and fault PDUs are encrypted.

The auth_value encoding is as follows:

 

typedef struct{
            u_int8      sub_type;
            u_int8      checksum_length;
            byte        [size_is(checksum_length)] checksum[];
            } auth_value_t;

The PDU to be protected is divided into two pieces: the RPC header and the PDU body composed of data generated by the stub's marshalling procedures. The following is passed to underlying security service in a call requesting privacy protection:

• the RPC header

• the PDU body, if any

• the desired checksum algorithm (corresponding to the value to be sent in the sub_type field).

The underlying security service returns the privacy protected PDU body, if any, and a checksum value.

If there was a PDU body, then the privacy protected PDU body replaces the original, unprotected PDU body in the PDU. The returned checksum value is inserted into the authentication verifier checksum field. The resulting PDU may then be transmitted.

If there was no PDU body, then the checksum value is inserted into the checksum field of the authentication verifier. The resulting PDU may then be transmitted.

The DCE: Security Services specification defines the algorithms used to create the protected PDU body and the checksum value.

Credentials Encoding

This section defines the contents of the optional auth_value fields in the bind, bind_ack, alter_context and alter_context_response PDUs as used for establishing credentials. The auth_value fields are modelled as IDL structure definitions. As in the RPC PDU definitions, the definitions assume no padding between elements, and they assume NDR transfer syntax.

For any protection level requested, including dce_c_authn_level_none, a bind PDU includes optional authentication data. If a new client principal is being introduced, either a bind for a new association or an alter_context on an existing association is used. The mutual authentication response is carried by the bind_ack or alter_context_response, respectively.

When security services are in effect, the credentials field is empty (cred_length=0) for an rpc_alter_context or rpc_alter_context_response PDU that is intended only to change non-security-related context, such as presentation context, transfer syntax, and the like.

The generic encoding is as follows:

 

typedef struct{
            u_int32     assoc_uuid_crc; /* checksum of assoc_uuid */
            u_int8      sub_type;
            u_int8      checksum_length;
            u_int16     cred_length;
            byte [size_is(cred_length)] credentials[];
            byte [size_is(checksum_length)] checksum[];
            } auth_value_t;

where:

• The assoc_uuid_crc field is defined by the client to be the value assoc_uuid_chksum, and is ignored on response.

• The credentials field depends on the auth_type, as specified in DCE Secret Key credentials Field Encoding .

• The checksum field depends on the level of service, as specified in DCE Secret Key credentials Field Encoding .

DCE Secret Key credentials Field Encoding

The following algorithm defines the credentials field encoding for auth_type=dce_c_rpc_authn_protocol_krb5:

For a bind or alter_context PDU with authentication level dce_c_authn_level_none, authentication service of dce_c_rpc_authn_protocol_krb5.

• If the authorisation service is dce_c_authz_name, the credentials field has the form:

   
  
  u_int8  authz_type=dce_c_authz_name;
  char    name[];     /* null-terminated local principal name */
                              /* size auth_length-1 */
  
  
  

• If the authorisation service is dce_c_authz_dce, the credentials field has the form:

   
  
  u_int8   authz_type=dce_c_authz_dce;
  byte     pac[];
  
  
  

  where the contents of the pac field is determined by the underlying security services and defined in the DCE: Security Services specification.

For a bind_ack or alter_context_response PDU with authentication level dce_c_authn_level_none, authentication service of dce_c_rpc_authn_protocol_krb5, and authorisation service of either dce_c_authz_name or dce_c_authz_dce, the credentials field has one of the following forms:

• If no error has occurred, then the auth_value field of the authentication verifier is empty (null).

• If an authentication error occurred then the auth_value field contains:

   
  
  u_int32 statusq  /* big-endian encoded */
  
  
  

For a bind or alter_context PDU with any authentication level except dce_c_authn_level_none, authentication service of dce_c_rpc_authn_protocol_krb5, and authorisation service of either dce_c_authz_name or dce_c_authz_dce, then the credentials field has the form:

 

byte   request[];

where the contents of the request field is determined by the underlying security services and defined in the DCE: Security Services specification.

For a bind_ack or alter_context_response PDU with any authentication level except dce_c_authn_level_none, authentication service of dce_c_rpc_authn_protocol_krb5, and authorisation service of either dce_c_authz_name or dce_c_authz_dce, then the credentials field has one of the following forms:

• If no error has occurred, the credentials field is encoded as

   
  
  byte   response[];
  
  
  

  where the contents of the response field are determined by the underlying security services and defined in the DCE: Security Services specification.

• If an authentication error occurred, the credentials field is encoded as

   
  
  byte   error[];
  
  
  

  where the contents of the error field are determined by the underlying security services and defined in the DCE: Security Services specification.

Security Services for Connectionless Protocol

The following sections specify security semantics and encodings for connectionless RPC protocol when the PDU header field auth_proto=dce_c_rpc_authn_protocol_krb5. Use of other protection services is permitted but outside the scope of this specification.

Server Receive Processing

On receiving a PDU, the connectionless protocol machine first locates the activity record that is associated with the client. This is determined through the activity ID. If no activity record is found, one is created, and if a security service is requested, the challenge/response exchange is initiated by performing the conversation manager callback for authenticated calls.

The protocol machine verifies the conversation manager callback response PDU. If the appropriate values of the this PDU match the authentication information of the activity record (refer to the DCE: Security Services specification), the security context is established; otherwise, an error PDU (reject PDU) is generated.

The server also initiates the challenge/response exchange if it cannot locate the received session key that is associated with the key sequence number.

Based on a valid security context, the server verifies the following for each received PDU:

• the authentication verifier according to the specific authentication protocol

• the selected level of per-PDU service.

If mismatches are detected, error PDUs (fault PDUs) are generated.

If the fragment number in the request PDU is 0 (zero), indicating that the PDU is the first PDU of a call, the current time is compared with the expiration time of the security context. If it has expired, an error PDU is generated.

Client Receive Processing

Client receive processing is identical to server receive processing, except that no attempt is made to learn the key through a challenge/response exchange.

Conversation Manager Encodings

The conv_who_are_you_auth() operation of the conversation manager provides a variable-length array of bytes on each leg of the operation by using a challenge/response exchange. Should the response to the challenge require more than a full packet of data, the status code of rpc_s_partial_credentials is returned. While the status code remains rpc_s_partial_credentials, subsequent calls to conv_who_are_you_auth_more() are made.

Challenge Request Data Encoding

The conversation manager challenge request PDU, which is generated by the server, is entirely in plaintext because the server does not necessarily share any keys with the client. It is transferred in the in_data parameter (that is, as the stub data of an RPC request PDU) of the conv_who_are_you_auth() and conv_who_are_you_auth_more() operations. When auth_proto=dce_c_rpc_authn_protocol_krb5, it is 12 bytes long and consists of:

 

typedef struct {
	u_int32		key_seq_num;	/* big endian */
	byte[8]		challenge;
	} in_data;

key_seq_num

The sequence number of the key requested by the server.

challenge

A 64-bit random value. See the DCE: Security Services specification for information on generating this confounder.

Response Data Encoding

The response is transferred as the out_data parameter (that is, as stub data of an RPC response PDU) of the conv_who_are_you_auth() and conv_who_are_you_auth_more() conversation manager operations. The contents of this PDU are specified in the DCE: Security Services specification.

Authentication Verifier Encodings

Connectionless PDUs contain an authentication verifier if the PDU header field auth_proto is non-zero. Otherwise, the authentication verifier is not present.

The encoding and length of the authentication verifier depends on the authentication service, as identified by the PDU header field auth_proto.

The authentication data encodings for the PDU authentication verifier are specified in the following sections for auth_proto=dce_c_rpc_authn_protocol_krb5.

Unless specified otherwise, the data types and values are encoded in the NDR transfer syntax. Note that no padding between elements within a data structure is assumed and that the alignment requirements for the PDU header (see Alignment ) also apply to the authentication verifier of the PDU trailer.

When the PDU header field auth_proto=dce_c_rpc_authn_protocol_krb5, every PDU contains a 20 or 24-byte authentication verifier. The first three fields of the verifier consist of a plaintext header followed by an 16-byte ciphertext authentication value, as follows:

 

typedef struct {
	u_int8			protection_level;
	u_int8			key_vers_num;
	byte[pad_length]	pad;
	byte[16]		auth_value;
	} auth_trailer_cl_t;

protection_level

The protection level of the RPC. It indicates the level of service as determined by the protection level values (see The Generic RPC Security Model ).

key_vers_num

The version number of the key that indicates the key used to encrypt or to calculate the checksum of any ciphertext in the authentication value.

pad

A padding field whose value is all zeros. The length of this array (pad_length) is 6 bytes for protection level dce_c_authn_level_privacy, 2 bytes otherwise.

auth_value

The ciphertext of the authentication verifier. The format of auth_value depends on the level of service. The plaintext is encoded in the transfer syntax as specified in the PDU header field drep.

The following sections describe the authentication value encodings for each protection level.

dce_c_authn_level_none

There is no authentication verifier in the PDU for this protection level.

dce_c_authn_level_connect

The auth_value field of the verifier is ignored for this level of service, which does not provide protection per PDU.

dce_c_authn_level_call

This level is not supported. Requests for this level will automatically be upgraded to dce_c_authn_level_pkt.

dce_c_authn_level_pkt

For per-PDU level, the underlying security service computes a 8-octet checksum of a plaintext that is supplied to the auth_value field of the authentication verifier. The plaintext is constructed as follows:

 

typedef struct {
        u_int32  seqnum;
        u_int32  fragnum;
        } plaintext;

seqnum

The sequence number of the call, as specified in the PDU header. If the server generates the authentication verifier, the high-order bit of the sequence number is set to 1, as indication for the direction.

fragnum

The fragment number of the call, as specified in the PDU header.

The DCE: Security Services specification defines the algorithms used to create the checksum value for the auth_value field.

dce_c_authn_level_integrity

For PDU-integrity level, the underlying security service computes a 16-octet checksum of the concatenated PDU header and body data that is supplied to the auth_value field of the authentication verifier.

The DCE: Security Services specification defines the algorithms used to create the checksum value for the auth_value field.

dce_c_authn_level_privacy

In contrast to the other security levels, this level also requires changes to the contents of the body data of the standard RPC PDUs. This level of service provides strong integrity protection for the entire PDU, plus privacy protection for the body data only.

The PDU to be protected is divided into two pieces: the RPC header and the PDU body composed of data generated by the stub's marshalling procedures. The following is passed to the underlying security service in a call requesting privacy protection:

• the RPC header

• the PDU body, if any

• the checksum field that was supplied as part of the out_data parameter in the conversation manager operation

• the sequence number of the call, as specified in the PDU header.

The underlying security service returns the privacy protected PDU body, if any, and a 16-octet checksum value.

If there was a PDU body, then the privacy protected PDU body replaces the original, unprotected PDU body in the PDU. Insert the returned checksum value into the auth_value field. The resulting PDU may then be transmitted.

If there was no PDU body, then insert the returned checksum value into the auth_value field. The resulting PDU may then be transmitted.

The DCE: Security Services specification defines the algorithms used to create the protected PDU body and the checksum value.

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.