Warning: This HTML rendition of the RFC is experimental. It is programmatically generated, and small parts may be missing, damaged, or badly formatted. However, it is much more convenient to read via web browsers. Refer to the PostScript or text renditions for the ultimate authority.

OSF DCE SIG P. Lin (IBM)
Request For Comments: 9.0 M. Leitch (IBM)
July 1992

EMBEDDED DCE SECURITY BRIDGE (EDB)

APPLICATION PROGRAMMING INTERFACE

INTRODUCTION

This document describes the application programming interface (API) of the Embedded DCE Security Bridge (EDB), and its implementation on top of existing DCE security facilities.

The embedded DCE security bridge is intended to provide an API and a set of supporting functions to enable usage of DCE security by various communication mechanisms. The supporting functions are packaged in the key manager, which manages secret keys, conversation keys, and other related information about the client-server security interaction.

Design Principles

The EDB is designed with the following principles in mind:

  1. Encapsulate common functions used by all or many communication mechanism implementions.
  2. Insulate communication mechanism implementations from changes in the underlying DCE security facilities, e.g., support of new authentication or cryptographic algorithms.
  3. Minimize the number and complexity of API calls that a communication mechanism implemention needs to make to the EDB.
  4. Minimize other modifications required in the communication mechanism implementions.
  5. Maximize portability of applicable EDB functions to different operating system platforms that support DCE.

Characteristics of EDB

The EDB has the following characteristics:

  1. It includes administrative functions required by its callers, such as server key management and principal definition.
  2. It provides its callers with explicit knowledge of the progress of the authentication exchange, which enables the explicit control of the exchange that is needed in optimizing the performance of communication mechanisms.
  3. In the area of delegation, it closely follows the delegation proposal for DCE 1.1 [RFC 3.0].
  4. It directly supports the use of DCE principal names and privilege attribute certificates (PACs) as parameters, without requiring format conversion.
  5. It has been mapped to the existing DCE security facilities to verify the feasibility and practicality of its use in the DCE environment.

Implementation Notes

The abstract description of the EDB API given in this document is designed to be implementation-independent. Additionally, a suggested high-level implementation flow in the DCE environment is given -- but this is always clearly marked as Notes on implementation on top of DCE security facilities.

It is suggested that the EDB API could occupy an intermediate position in the DCE environment, below GSS-API and above actual security mechanisms. The EDB API would thus be available for security-knowledgeable, performance-conscious applications.

APPLICATION PROGRAMMING INTERFACE

The API functions for server principal definition, registration (with the EDB), authentication, communications integrity and communications confidentiality are described in separate sections below.

To facilitate portability to different platforms, usage of all functions except those identified as for authorized callers only\*(f!

Authorized callers are trusted by the local operating system and have special privileges not available to general callers.
is restricted indirectly. On multi-user operating systems, client credentials caches and key storage maintained by the key manager are protected by local system access control. Since each function accesses one or both of these data structures, the caller must have the required access permissions in order for a call to complete successfully.\*(f!
The implementation should perform appropriate clean-up for calls that do not complete successfully.

Server Principal Definition

Functions for general callers

Define server principal to DCE registry

  1. Function name: edb_define_principal
  2. Input parameters:
    1. admin_userid -- Local userid of administrator.\*(f!
      The name by which the administrator is known on the local system.
    2. principal -- Name of server principal to be defined.
    3. init_passwd -- Initial password of server principal.
  3. Output parameters:
    1. status -- Completion status.
  4. Description: This function is intended to be called by an automated installation procedure running under the identity of an administrator to define a server principal to the DCE registry.
  5. Notes on implementation on top of DCE security facilities:

    This function assumes that: (1) The DCE registry in the cell has been integrated with the local machine's registry. (2) The administrator identified by admin_userid is a DCE principal who has privileges to create principals and accounts in the registry; since the DCE security server checks these privileges before allowing updates to the registry, edb_define_principal does not need to be an authorized call.

    1. Obtain the system id (machine principal id) of the local system.
    2. Call the extended sec_idmap interface\*(f!
      Provided as part of the integration of the local registry with the DCE registry.
      to map the (local userid, system id) pair for the administrator to a DCE principal name. The mapping information is stored in the integrated DCE registry.
    3. Request a ticket-granting ticket (TGT) for the administrator principal from the DCE security server.
    4. Get the administrator's key from the local registry.
    5. Decrypt the TGT envelope with the key. The envelope contains, in addition to the TGT, an associated conversation key.
    6. Request a PTGT for the administrator principal from the DCE security server.
    7. Decrypt the PTGT envelope with the TGS conversation key.
    8. Set up a login context for the administrator.
    9. Define the server principal to the DCE registry.
    10. Define an account for the server principal in the DCE registry, supplying the initial password.

Registration with EDB

Functions for general callers

Register a general client

  1. Function name: edb_register
  2. Input parameters:
    1. caller_name -- Name of calling client.
  3. Output parameters:
    1. caller_token -- Caller's token for interactions with key manager.
    2. status -- Completion status.
  4. Description: This function is called by a client to register itself with the key manager at start-up time.
  5. Notes on implementation on top of DCE security facilities:
    1. Set up storage for conversation keys and related information.
    2. The key manager returns a token for the caller to use in subsequent interactions.

De-register a general client

  1. Function name: edb_deregister

  2. Input-output parameters:
    1. caller_token -- Caller's token for interactions with key manager.
  3. Output parameters:
    1. status -- Completion status.
  4. Description: This function is called by a client to de-register itself with the key manager at shut-down time.
  5. Notes on implementation on top of DCE security facilities:
    1. Erase storage set aside for the caller's conversation keys and related information.
    2. Invalidate the caller's token.

Functions for authorized callers only

Although all functions in this section are indicated as authorized calls, edb_register_server and edb_deregister_server can be implemented as unauthorized calls on platforms that do not support the distinction between general and authorized callers.

Register a server or trusted client

  1. Function name: edb_register_server
  2. Input parameters:
    1. caller_name -- Name of calling server or trusted client.
    2. init_passwd -- Initial password for server or trusted client.
  3. Output parameters:
    1. caller_token -- Caller's token for interactions with key manager.
    2. status -- Completion status.
  4. Description: This function is called by a server or a trusted client (one that logs users in to DCE using edb_trusted_login) to register itself with the key manager at start-up time, and start up automatic key management.
  5. Notes on implementation on top of DCE security facilities:

    This function assumes that the initial password supplied has also been entered in the DCE registry by an administrator.

    1. Check that the caller is authorized.
    2. Set up storage for conversation keys and related information.
    3. Pass the initial password to the key manager. The key manager converts this password to the initial server key and stores the key.
    4. The key manager will log in to DCE as the caller and obtain its key expiration time. This is the next time at which the caller's key will be automatically updated.
    5. The key manager returns a token for the caller to use in subsequent interactions.

De-register a server or trusted client

  1. Function name: edb_deregister_server
  2. Input-output parameters:
    1. caller_token -- Caller's token for interactions with key manager.
  3. Output parameters:
    1. status -- Completion status.
  4. Description: This function is called by a server or a trusted client (one that logs users in to DCE using edb_trusted_login) to de-register itself with the key manager at shut-down time.
  5. Notes on implementation on top of DCE security facilities:
    1. Check that the caller is authorized.
    2. Erase storage set aside for the caller's conversation keys and related information.
    3. Terminate automatic key management for the caller.
    4. Invalidate the caller's token.

Register multiple callers with key manager

  1. Function name: edb_register_multiple
  2. Input parameters:
    1. list_length -- Length of caller_name_list, c_or_s_list, init_passwd_list, caller_token_list and status_list.
    2. caller_name_list -- List of client or server names.
    3. c_or_s_list -- List of flags: = 1 if server or trusted client, = 0 otherwise.
    4. init_passwd_list -- List of initial passwords (an element in this list is null if the corresponding element in c_or_s_list = 0).
  3. Output parameters:
    1. caller_token_list -- List of caller tokens for interactions with key manager.
    2. status_list -- List of completion statuses.
  4. Description: This function is called by an authorized caller to register a list of clients and servers with the key manager at start-up time.
  5. Notes on implementation on top of DCE security facilities:
    1. Check that the caller is authorized.
    2. For each caller in caller_name_list:
      1. If the corresponding element of c_or_s_list = 1 (server or trusted client), invoke edb_register_server with the corresponding elements of init_passwd_list, caller_token_list and status_list as parameters.
      2. Otherwise, invoke edb_register with the corresponding elements of caller_token_list and status_list as parameters.

De-register multiple callers with key manager

  1. Function name: edb_deregister_multiple
  2. Input-output parameters:
    1. list_length -- Length of caller_token_list and status_list.
    2. caller_token_list -- List of caller tokens for interactions with key manager.
  3. Output parameters:
    1. status_list -- List of completion statuses.
  4. Description: This function is called by an authorized caller to de-register a list of clients and servers with the key manager at shut-down time.
  5. Notes on implementation on top of DCE security facilities:
    1. Check that the caller is authorized.
    2. For each caller in caller_name_list:
      1. If the caller is a server or trusted client, invoke edb_deregister_server with the corresponding elements of caller_token_list and status_list as parameters.
      2. Otherwise, invoke edb_deregister with the corresponding elements of caller_token_list and status_list as parameters.

Authentication

In the EDB API, the words ticket and authenticator are used as generic terms for (full) authentication token and light-weight authentication token respectively.

Note that the format of the authenticator and authentication reply generated by the API functions in this section can be dependent on the specific communication mechanism calling the EDB.

Notes on implementation on top of DCE security facilities: For the edb_get_delegation, edb_receive_delegation and edb_get_client_ticket functions, the privilege ticket-granting ticket (PTGT) is forwarded because the client does not know which servers will be in the chain beyond the first one. This scheme is suitable where the servers involved are trusted to fully assume the client's identity. Note that this scheme closely parallels the design for delegation under authenticated RPC in OSF DCE 1.1, which is sketched out in [RFC 3.0]. It is proposed that the case in which trust in intermediate servers is not warranted be addressed in conjunction with delegation in OSF DCE 1.1, since the support for this case requires changes to the privilege server. These changes should not affect the EDB API, however.

Calling sequences

Client on workstation to server on host

For the client on workstation to server on host configurations, edb_get_ticket and edb_parse_ticket are the only functions required to authenticate the client to the server. The other two functions, edb_build_auth_reply and edb_parse_auth_reply, are used to authenticate the server to the client, in order to achieve mutual authentication.

A typical end-to-end calling sequence without mutual authentication would be:

  1. edb_get_ticket

    A client gets a ticket to authenticate itself to the server.

  2. edb_parse_ticket

    The server parses the ticket from the client.

A typical end-to-end calling sequence with mutual authentication would be:

  1. edb_get_ticket

    A client gets a ticket to authenticate itself to the server.

  2. edb_parse_ticket

    The server parses the ticket from the client.

  3. edb_build_auth_reply

    The first server builds an authentication reply to authenticate itself to the client.

  4. edb_parse_auth_reply

    The client parses the authentication reply from the first server.

Server on host to server on host

The functions edb_get_delegation, edb_receive_delegation and edb_get_client_ticket are intended for the server on host to server on host configuration.

A typical end-to-end calling sequence with delegation would be:

  1. edb_get_ticket

    A client gets a ticket to authenticate itself to the first server in a chain.

  2. edb_parse_ticket

    The first server parses the ticket from the client.

  3. edb_build_auth_reply

    The first server builds an authentication reply to authenticate itself to the client.

  4. edb_parse_auth_reply

    The client parses the authentication reply from the first server.

  5. edb_get_delegation

    The client gets a delegation token to forward to the first server.

  6. edb_receive_delegation

    The first server receives the delegation token from the client.

  7. edb_get_client_ticket

    The first server gets a ticket on behalf of the client to the second server in the chain.

Note that mutual authentication is included because the client may wish to verify the identity of the server before forwarding its delegation token. If it is acceptable to forgo this verification, then the calling sequence can be simplified to the following, in which the client gets both the ticket for the first server and its delegation token and forwards the two items to the server together.

  1. edb_get_ticket

    A client gets a ticket to authenticate itself to the first server in a chain.

  2. edb_get_delegation

    The client gets a delegation token to forward to the first server.

  3. edb_parse_ticket

    The first server parses the ticket from the client.

  4. edb_receive_delegation

    The first server receives the delegation token from the client.

  5. edb_get_client_ticket

    The first server gets a ticket on behalf of the client to the second server in the chain.

Client on host to server on workstation

The last two functions (edb_trusted_login, edb_trusted_logout) are intended for the client on host to server on workstation configuration.

Typical calling sequences for this configuration are the same as those described in the sections on Client on workstation to server on host and Server on host to server on host, except that edb_trusted_login is used to log the client or the user on whose behalf it acts into DCE, in order to provide the login context needed by these calling sequences, and edb_trusted_logout is used to purge the login context.

Functions for general callers

Get ticket

  1. Function name: edb_get_ticket
  2. Input parameters:
    1. caller_token -- Token for calling client.
    2. server_name -- Name of target server.
    3. ticket_req -- = 1 if both ticket and authenticator are required, = 0 if only authenticator is required.
  3. Input-output parameters:
    1. conv_token -- Conversation identifier (null if ticket_req = 1).
  4. Output parameters:
    1. ticket -- Ticket for target server (null if ticket_req = 0, unless the previous ticket has expired).
    2. authent -- Authenticator.
    3. status -- Completion status.
  5. Description: This function is called by a client to get a ticket, an authenticator and a conversation key for a target server. There is an option to get an authenticator only.
  6. Notes on implementation on top of DCE security facilities:

    This function assumes that the calling client, or the user on whose behalf it acts, has logged in to DCE\*(f!

    Via dce_login, the DCE sec_login API (see [OSF]), or edb_trusted_login.
    so that a login context is available.
    1. Get the current login context.
    2. If only an authenticator is required:
      1. Get the conversation key for the target server.
        1. If there is an unexpired credential (ticket and conversation key) in the client's credentials cache, the conversation key will be returned.
        2. Otherwise, a credential (ticket and new conversation key) will be obtained from the DCE security server.
      2. Build an authenticator. If a new conversation key was returned by the previous step, it is included in the authenticator as the subkey, so that it will be used for subsequent communication between the client and the target server.
      3. Encrypt the authenticator in the conversation key identified by conv_token.
      4. Pass the new conversation key to the key manager for storage under conv_token.
    3. Otherwise:
      1. Get a credential (ticket and conversation key) for the target server.
        1. If there is an unexpired credential in the client's credentials cache, it will be returned.
        2. Otherwise, a credential will be obtained from the DCE security server. Pass the conversation key to the key manager for storage and get the conv_token returned by the key manager.
      2. Build an authenticator.
      3. Encrypt the authenticator in the conversation key.

Parse ticket

  1. Function name: edb_parse_ticket
  2. Input parameters:
    1. caller_token -- Token for calling server.
    2. ticket -- Ticket received (null if only the authenticator needs to be verified).
    3. authent -- Authenticator.
  3. Input-output parameters:
    1. conv_token -- Conversation identifier (supplied as input if only the authenticator needs to be verified).
  4. Output parameters:
    1. userid -- Local userid.\*(f!
      A name known to the local operating system.
    2. principal -- DCE principal name.
    3. pac -- Privilege attribute certificate.
    4. status -- Completion status.
  5. Description: This function is called by a server to validate an incoming ticket and the associated authenticator, and obtain the client identity and conversation key. There is an option to verify an authenticator only.
  6. Notes on implementation on top of DCE security facilities:
    1. If only the authenticator needs to be verified:
      1. Get the conversation key identified by conv_token from the key manager.
      2. Decrypt and verify the authenticator.
      3. Extract the DCE principal name from the authenticator.
      4. If there is a subkey included in the authenticator, pass it to the key manager for storage under conv_token.
    2. Otherwise:
      1. Get the server's key from the key manager.
      2. Decrypt the ticket.
      3. Check that the ticket has not expired.
      4. Decrypt the authenticator with the conversation key in the ticket. Verify the authenticator to ascertain that the ticket is not a replay.\*(f!
        It is assumed that a replay cache is not required.
      5. Extract the privilege attribute certificate (PAC) from the ticket.
      6. Extract the (local userid, system id) pair from the PAC and check that the system id matches the id of the local system.\*(f!
        The local userid is typically a character string that represents the user on the local system. It identifies the user for the purposes of access control and other system functions.
      7. Translate the principal UUID in the PAC to the corresponding principal name.
      8. Pass the conversation key to the key manager for storage.
        1. If a subkey is included in the authenticator, it is the actual conversation key.
        2. Otherwise, extract the conversation key from the ticket.
      9. The key manager returns a conv_token.

Build authentication reply

  1. Function name: edb_build_auth_reply
  2. Input parameters:
    1. caller_token -- Token for calling server.
    2. principal_name -- DCE principal name associated with target client.
    3. conv_token -- Conversation identifier.
  3. Output parameters:
    1. auth_reply -- Authentication reply.
    2. status -- Completion status.
  4. Description: This function is called by a server to build an authentication reply used to complete a mutual authentication exchange with a target client.
  5. Notes on implementation on top of DCE security facilities:
    1. Build an authentication reply.
    2. Get the conversation key identified by conv_token from the key manager.
    3. Encrypt the authentication reply.

Parse authentication reply

  1. Function name: edb_parse_auth_reply
  2. Input parameters:
    1. caller_token -- Token for calling client.
    2. auth_reply -- Authentication reply received.
    3. conv_token -- Conversation identifier.
  3. Output parameters:
    1. status -- Completion status.
  4. Description: This function is called by a client to validate an incoming authentication reply from a target server.
  5. Notes on implementation on top of DCE security facilities:
    1. Get the conversation key identified by conv_token from the key manager.
    2. Decrypt the authentication reply.
    3. Verify the authentication reply.

Get delegation token

  1. Function name: edb_get_delegation
  2. Input parameters:
    1. caller_token -- Token for calling client.
    2. login_context -- Pointer to client's login context.
    3. server_name -- Name of target server.
    4. conv_token -- Conversation identifier.
  3. Output parameters:
    1. deleg_env -- Envelope containing delegation token and associated conversation key between client and delegation server.
    2. status -- Completion status.
  4. Description: This function is called by a client to get a delegation token and the associated conversation key between the client and the delegation token server (DS key) to be forwarded to a target server. Typically, the client would have completed a mutual authentication exchange with the server before forwarding the delegation token.
  5. Notes on implementation on top of DCE security facilities:

    This function assumes that the calling client, or the user on whose behalf it acts, has logged in to DCE\*(f!

    Via dce_login, the DCE sec_login API (see [OSF]), or edb_trusted_login.
    so that a login context is available.
    1. Get a PTGT for the cell of the target server, together with the associated PS key.
      1. If there is an unexpired PTGT in the client's credentials cache that satisfies the requirements, it will be returned along with the associated PS key.
      2. Otherwise, a PTGT and PS key will be obtained from the DCE security server.
    2. Get the conversation key identified by conv_token from the key manager.
    3. Encrypt the PTGT and PS key to give the PTGT envelope.

Receive delegation token

  1. Function name: edb_receive_delegation
  2. Input parameters:
    1. caller_token -- Token for calling server.
    2. deleg_env -- Envelope containing delegation token and associated conversation key to the delegation token server.
    3. conv_token -- Conversation identifier.
  3. Output parameters:
    1. status -- Completion status.
  4. Description: This function is called by a server to store an incoming delegation token and the associated conversation key to the delegation token server (DS key).
  5. Notes on implementation on top of DCE security facilities:
    1. Get the conversation key identified by conv_token from the key manager.
    2. Decrypt the PTGT envelope to give the PTGT and the associated PS key.
    3. Pass the PTGT and PS key to the key manager for storage. They will be stored with the conversation key identified by conv_token.

Get ticket for client

  1. Function name: edb_get_client_ticket
  2. Input parameters:
    1. caller_token -- Token for calling server.
    2. conv_token -- Conversation identifier.
    3. server_name -- Name of target server.
    4. ticket_req -- = 1 if both ticket and authenticator are required, = 0 if only authenticator is required.
  3. Output parameters:
    1. ticket -- Client's ticket for target server (null if ticket_req = 0, unless the previous ticket has expired).
    2. authent -- Authenticator.
    3. status -- Completion status.
  4. Description: This function is called by a server on behalf of one its clients to get a ticket and an authenticator for another target server. There is an option to get an authenticator only.
  5. Notes on implementation on top of DCE security facilities:
    1. If only an authenticator is required:
      1. Get the client ticket and conversation key identified by conv_token from the key manager.
      2. If the client ticket has expired:
        1. Get the client PTGT and PS key identified by conv_token from the key manager.
        2. Get a credential (ticket and new conversation key) for the target server, by presenting the client PTGT to the DCE security server. Note that the PS key is used to encrypt the envelope containing the PTGT before it is sent to the DCE security server.
        3. Pass the client ticket to the key manager for storage under conv_token.
      3. Build an authenticator that includes the conversation key identified by conv_token as the subkey. This conversation key is used for subsequent communication between the calling server and the target server.
      4. Encrypt the authenticator in the new conversation key.
    2. Otherwise:
      1. Get the conversation key, client PTGT, and PS key identified by conv_token from the key manager.
      2. Get a credential (ticket and new conversation key) for the target server, by presenting the client PTGT to the DCE security server. Note that the PS key is used to encrypt the envelope containing the PTGT before it is sent to the DCE security server.
      3. Pass the client ticket to the key manager for storage under conv_token.
      4. Build an authenticator that includes the conversation key identified by conv_token as the subkey. This conversation key is used for subsequent communication between the calling server and the target server.
      5. Encrypt the authenticator in the new conversation key.

Functions for authorized callers only

Trusted login

  1. Function name: edb_trusted_login
  2. Input parameters:
    1. caller_token -- Token for calling client.
    2. userid -- Local userid.\*(f!
      A name known to the local operating system.
  3. Output parameters:
    1. login_context -- Pointer to user's login context.
    2. status -- Completion status.
  4. Description: This function is called by a trusted client to log a user in to DCE.
  5. Notes on implementation on top of DCE security facilities:

    This function assumes that: (1) The DCE registry in the cell has been integrated with the local machine's registry. (2) The calling client has registered with the key manager.

    1. Check that the caller is authorized.
    2. Obtain the system id (machine principal id) of the local system.
    3. Call the extended sec_idmap interface\*(f!
      Provided as part of local registry integration.
      to map the (local userid, system id) pair to a DCE principal name. The mapping information is stored in the integrated DCE registry.
    4. Request a ticket-granting ticket (TGT) for the principal from the DCE security server.
    5. Get the local user's key from the local registry.
    6. Decrypt the TGT envelope with the key. The envelope contains, in addition to the TGT, an associated conversation key.
    7. Request a PTGT for the principal from the DCE security server.
    8. Decrypt the PTGT envelope with the TGS conversation key.
    9. Set up a login context for the user.

Trusted logout

  1. Function name: edb_trusted_logout
  2. Input parameters:
    1. caller_token -- Token for calling client.
  3. Input-output parameters:
    1. login_context -- Pointer to user's login context.
  4. Output parameters:
    1. status -- Completion status.
  5. Description: This function is called by a trusted client to log a user out of DCE.
  6. Notes on implementation on top of DCE security facilities:
    1. Purge the user's login context.
    2. Purge the user's credentials cache.

Communications Integrity

Functions for general callers

Build verifier

  1. Function name: edb_build_verifier
  2. Input parameters:
    1. caller_token -- Token for calling client or server.
    2. length -- Length of data.
    3. data -- Pointer to data to be sent.
    4. conv_token -- Conversation identifier.
    5. verifier -- Pointer to buffer for verifier.
  3. Output parameters:
    1. status -- Completion status.
  4. Description: This function is called by a client or a server to build an integrity verifier for data to be sent.
  5. Notes on implementation on top of DCE security facilities:
    1. Compute an MD5 digest over the input data.
    2. Get the conversation key identified by conv_token from the key manager.
    3. Encrypt the digest using DES in cipher block chaining mode to give the verifier.

Check verifier

  1. Function name: edb_check_verifier
  2. Input parameters:
    1. caller_token -- Token for calling client or server.
    2. length -- Length of data.
    3. data -- Pointer to data received.
    4. verifier -- Verifier received.
    5. conv_token -- Conversation identifier.
  3. Output parameters:
    1. status -- Completion status.
  4. Description: This function is called by a client or a server to check the integrity of data received.
  5. Notes on implementation on top of DCE security facilities:
    1. Compute an MD5 digest over the input data.
    2. Get the conversation key identified by conv_token from the key manager.
    3. Encrypt the digest using DES in cipher block chaining mode to give a verifier.
    4. Compare this verifier with the verifier received.

Communications Confidentiality

Functions for general callers

Encrypt data

  1. Function name: edb_encrypt_data
  2. Input parameters:
    1. caller_token -- Token for calling client or server.
    2. length -- Length of data.
    3. data -- Pointer to data to be encrypted.
    4. conv_token -- Conversation identifier.
    5. enc_length -- Length of buffer for encrypted data.
    6. enc_data -- Pointer to buffer for encrypted data.
  3. Output parameters:
    1. status -- Completion status.
  4. Description: This function is called by a client or a server to encrypt data to be sent. It also builds a verifier for integrity checking purposes.
  5. Notes on implementation on top of DCE security facilities:
    1. Compute a CRC-32 checksum\*(f!
      A CRC-32 checksum is considered to be acceptable since it is more difficult to tamper with encrypted data.
      over the encrypted data.
    2. Get the conversation key identified by conv_token from the key manager.
    3. Encrypt the checksum followed by the input data using DES in cipher block chaining mode to give enc_data.

Decrypt data

  1. Function name: edb_decrypt_data
  2. Input parameters:
    1. caller_token -- Token for calling client or server.
    2. length -- Length of data.
    3. data -- Pointer to data to be decrypted.\*(f!
      Since this data was generated by edb_encrypt_data, it includes a checksum for integrity checking purposes.
    4. conv_token -- Conversation identifier.
    5. dec_length -- Length of buffer for decrypted data.
    6. dec_data -- Pointer to buffer for decrypted data.
  3. Output parameters:
    1. status -- Completion status.
  4. Description: This function is called by a client or a server to decrypt data received and check its integrity.
  5. Notes on implementation on top of DCE security facilities:
    1. Get the conversation key identified by conv_token from the key manager.
    2. Decrypt the data received to give dec_data.
    3. Separate the checksum from the body of the data.
    4. Compute a CRC-32 checksum\*(f!
      A CRC-32 checksum is considered to be acceptable since it is more difficult to tamper with encrypted data.
      over the body of the data.
    5. Compare the checksum with the checksum received.

GLOSSARY

  1. Automatic key management

    Automatic renewal of a server's key when it expires. This involves generating a new key randomly, storing it in both local key storage and the DCE registry. Each expired key is retained in local key storage for a period of time sufficient for all tickets that could have encrypted with that key to expire.

  2. Client

    A process that makes use of a network service on behalf of a user. Note that in some cases a server may itself be a client of some other server (e.g., a print server may be a client of a file server).

  3. Envelope

    An encrypted data structure.

  4. Principal

    A client, server or machine instance that participates in secure network communication. Principals are represented by entries in the DCE registry.

REFERENCES

[OSF]
OSF DCE Version 1.0 DCE Application Development Guide, Revision 1.0, December 31, 1991.
[RFC 3.0]
Joe Pato, Extending the DCE Authorization Model to Support Practical Delegation (Extended Summary), June 1992.

AUTHORS' ADDRESSES

Ping Lin Internet email: plin@torolab5.vnet.ibm.com
Distributed Software Products Telephone: +1-416-448-3942
IBM Canada Laboratory
Stn. 2G, 1150 Eglinton Avenue East
Toronto, Ontario
CANADA M3C 1H7

Mark Leitch Internet email: mleitch@torolab5.vnet.ibm.com
Distributed Software Products Telephone: +1-416-448-4431
IBM Canada Laboratory
Stn. 2G, 1150 Eglinton Avenue East
Toronto, Ontario
CANADA M3C 1H7