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:
-
Encapsulate common functions used by all or many communication
mechanism implementions.
-
Insulate communication mechanism implementations from changes
in the underlying DCE security facilities, e.g., support of new
authentication or cryptographic algorithms.
-
Minimize the number and complexity of API calls that a communication
mechanism implemention needs to make to the EDB.
-
Minimize other modifications required in the communication mechanism
implementions.
-
Maximize portability of applicable EDB functions to different
operating system platforms that support DCE.
Characteristics of EDB
The EDB has the following characteristics:
-
It includes administrative functions required by its callers, such as
server key management and principal definition.
-
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.
-
In the area of delegation, it closely follows the delegation proposal
for DCE 1.1 [RFC 3.0].
-
It directly supports the use of DCE principal names and privilege attribute
certificates (PACs) as parameters, without requiring format conversion.
-
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
-
Function name:
edb_define_principal
-
Input parameters:
-
admin_userid -- Local userid of administrator.\*(f!
The name by which the administrator is known on the local system.
-
principal -- Name of server principal to be defined.
-
init_passwd -- Initial password of server principal.
-
Output parameters:
-
status -- Completion status.
-
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.
-
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.
-
Obtain the system id (machine principal id) of the local system.
-
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.
-
Request a ticket-granting ticket (TGT)
for the administrator principal from the DCE security server.
-
Get the administrator's key from the local registry.
-
Decrypt the TGT envelope with the key. The envelope contains,
in addition to the TGT, an associated conversation key.
-
Request a PTGT for the administrator principal from the DCE security server.
-
Decrypt the PTGT envelope with the TGS conversation key.
-
Set up a login context for the administrator.
-
Define the server principal to the DCE registry.
-
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
-
Function name:
edb_register
-
Input parameters:
-
caller_name -- Name of calling client.
-
Output parameters:
-
caller_token -- Caller's token for interactions with key manager.
-
status -- Completion status.
-
Description:
This function is called by a client to register itself
with the key manager at start-up time.
-
Notes on implementation on top of DCE security facilities:
-
Set up storage for conversation keys and related information.
-
The key manager returns a token for the caller to use in
subsequent interactions.
De-register a general client
-
Function name:
edb_deregister
-
Input-output parameters:
-
caller_token -- Caller's token for interactions with key manager.
-
Output parameters:
-
status -- Completion status.
-
Description:
This function is called by a client to de-register itself
with the key manager at shut-down time.
-
Notes on implementation on top of DCE security facilities:
-
Erase storage set aside for the caller's conversation keys
and related information.
-
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
-
Function name:
edb_register_server
-
Input parameters:
-
caller_name -- Name of calling server or trusted client.
-
init_passwd -- Initial password for server or trusted client.
-
Output parameters:
-
caller_token -- Caller's token for interactions with key manager.
-
status -- Completion status.
-
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.
-
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.
-
Check that the caller is authorized.
-
Set up storage for conversation keys and related information.
-
Pass the initial password to the key manager. The key
manager converts this password to the initial server key and stores the key.
-
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.
-
The key manager returns a token for the caller to use in
subsequent interactions.
De-register a server or trusted client
-
Function name:
edb_deregister_server
-
Input-output parameters:
-
caller_token -- Caller's token for interactions with key manager.
-
Output parameters:
-
status -- Completion status.
-
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.
-
Notes on implementation on top of DCE security facilities:
-
Check that the caller is authorized.
-
Erase storage set aside for the caller's conversation keys
and related information.
-
Terminate automatic key management for the caller.
-
Invalidate the caller's token.
Register multiple callers with key manager
-
Function name:
edb_register_multiple
-
Input parameters:
-
list_length -- Length of caller_name_list, c_or_s_list, init_passwd_list,
caller_token_list and status_list.
-
caller_name_list -- List of client or server names.
-
c_or_s_list -- List of flags:
= 1 if server or trusted client, = 0 otherwise.
-
init_passwd_list -- List of initial passwords (an element in this
list is null if the corresponding element in c_or_s_list = 0).
-
Output parameters:
-
caller_token_list -- List of caller tokens for interactions with
key manager.
-
status_list -- List of completion statuses.
-
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.
-
Notes on implementation on top of DCE security facilities:
-
Check that the caller is authorized.
-
For each caller in caller_name_list:
-
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.
-
Otherwise, invoke edb_register with the corresponding elements
of caller_token_list and status_list as parameters.
De-register multiple callers with key manager
-
Function name:
edb_deregister_multiple
-
Input-output parameters:
-
list_length -- Length of caller_token_list and status_list.
-
caller_token_list -- List of caller tokens for interactions with
key manager.
-
Output parameters:
-
status_list -- List of completion statuses.
-
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.
-
Notes on implementation on top of DCE security facilities:
-
Check that the caller is authorized.
-
For each caller in caller_name_list:
-
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.
-
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:
-
edb_get_ticket
A client gets a ticket to authenticate itself to the server.
-
edb_parse_ticket
The server parses the ticket from the client.
A typical end-to-end calling sequence with mutual authentication would
be:
-
edb_get_ticket
A client gets a ticket to authenticate itself to the server.
-
edb_parse_ticket
The server parses the ticket from the client.
-
edb_build_auth_reply
The first server builds an authentication reply to authenticate
itself to the client.
-
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:
-
edb_get_ticket
A client gets a ticket to authenticate itself to the first server
in a chain.
-
edb_parse_ticket
The first server parses the ticket from the client.
-
edb_build_auth_reply
The first server builds an authentication reply to authenticate
itself to the client.
-
edb_parse_auth_reply
The client parses the authentication reply from the first server.
-
edb_get_delegation
The client gets a delegation token to forward to the first server.
-
edb_receive_delegation
The first server receives the delegation token from the client.
-
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.
-
edb_get_ticket
A client gets a ticket to authenticate itself to the first server
in a chain.
-
edb_get_delegation
The client gets a delegation token to forward to the first server.
-
edb_parse_ticket
The first server parses the ticket from the client.
-
edb_receive_delegation
The first server receives the delegation token from the client.
-
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
-
Function name:
edb_get_ticket
-
Input parameters:
-
caller_token -- Token for calling client.
-
server_name -- Name of target server.
-
ticket_req -- = 1 if both ticket and authenticator are required,
= 0 if only authenticator is required.
-
Input-output parameters:
-
conv_token -- Conversation identifier (null if ticket_req = 1).
-
Output parameters:
-
ticket -- Ticket for target server (null if ticket_req = 0, unless
the previous ticket has expired).
-
authent -- Authenticator.
-
status -- Completion status.
-
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.
-
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.
-
Get the current login context.
-
If only an authenticator is required:
-
Get the conversation key for the target server.
-
If there is an unexpired credential (ticket and conversation key) in the
client's credentials cache, the conversation key will be returned.
-
Otherwise, a credential (ticket and new conversation key) will be obtained
from the DCE security server.
-
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.
-
Encrypt the authenticator in the conversation key identified by conv_token.
-
Pass the new conversation key to the key manager for storage under
conv_token.
-
Otherwise:
-
Get a credential (ticket and conversation key)
for the target server.
-
If there is an unexpired credential in the client's credentials cache,
it will be returned.
-
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.
-
Build an authenticator.
-
Encrypt the authenticator in the conversation key.
Parse ticket
-
Function name:
edb_parse_ticket
-
Input parameters:
-
caller_token -- Token for calling server.
-
ticket -- Ticket received (null if only the authenticator needs to be
verified).
-
authent -- Authenticator.
-
Input-output parameters:
-
conv_token -- Conversation identifier (supplied as input if only the
authenticator needs to be verified).
-
Output parameters:
-
userid -- Local userid.\*(f!
A name known to the local operating system.
-
principal -- DCE principal name.
-
pac -- Privilege attribute certificate.
-
status -- Completion status.
-
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.
-
Notes on implementation on top of DCE security facilities:
-
If only the authenticator needs to be verified:
-
Get the conversation key identified by conv_token from the key
manager.
-
Decrypt and verify the authenticator.
-
Extract the DCE principal name from the authenticator.
-
If there is a subkey included in the authenticator, pass it
to the key manager for storage under conv_token.
-
Otherwise:
-
Get the server's key from the key manager.
-
Decrypt the ticket.
-
Check that the ticket has not expired.
-
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.
-
Extract the privilege attribute certificate (PAC) from the ticket.
-
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.
-
Translate the principal UUID in the PAC to the
corresponding principal name.
-
Pass the conversation key to the key manager for storage.
-
If a subkey is included in the authenticator, it is the actual
conversation key.
-
Otherwise, extract the conversation key from the ticket.
-
The key manager returns a conv_token.
Build authentication reply
-
Function name:
edb_build_auth_reply
-
Input parameters:
-
caller_token -- Token for calling server.
-
principal_name -- DCE principal name associated with target client.
-
conv_token -- Conversation identifier.
-
Output parameters:
-
auth_reply -- Authentication reply.
-
status -- Completion status.
-
Description:
This function is called by a server to build an authentication
reply used to complete a mutual authentication exchange with a
target client.
-
Notes on implementation on top of DCE security facilities:
-
Build an authentication reply.
-
Get the conversation key identified by conv_token
from the key manager.
-
Encrypt the authentication reply.
Parse authentication reply
-
Function name:
edb_parse_auth_reply
-
Input parameters:
-
caller_token -- Token for calling client.
-
auth_reply -- Authentication reply received.
-
conv_token -- Conversation identifier.
-
Output parameters:
-
status -- Completion status.
-
Description:
This function is called by a client to validate an incoming
authentication reply from a target server.
-
Notes on implementation on top of DCE security facilities:
-
Get the conversation key identified by conv_token
from the key manager.
-
Decrypt the authentication reply.
-
Verify the authentication reply.
Get delegation token
-
Function name:
edb_get_delegation
-
Input parameters:
-
caller_token -- Token for calling client.
-
login_context -- Pointer to client's login context.
-
server_name -- Name of target server.
-
conv_token -- Conversation identifier.
-
Output parameters:
-
deleg_env -- Envelope containing delegation token
and associated conversation key between client and delegation server.
-
status -- Completion status.
-
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.
-
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.
-
Get a PTGT for the cell of the target server,
together with the associated PS key.
-
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.
-
Otherwise, a PTGT and PS key
will be obtained from the DCE security server.
-
Get the conversation key identified by conv_token from the
key manager.
-
Encrypt the PTGT and PS key
to give the PTGT envelope.
Receive delegation token
-
Function name:
edb_receive_delegation
-
Input parameters:
-
caller_token -- Token for calling server.
-
deleg_env -- Envelope containing delegation token
and associated conversation key to the delegation token server.
-
conv_token -- Conversation identifier.
-
Output parameters:
-
status -- Completion status.
-
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).
-
Notes on implementation on top of DCE security facilities:
-
Get the conversation key identified by conv_token
from the key manager.
-
Decrypt the PTGT envelope to give the PTGT and the associated PS
key.
-
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
-
Function name:
edb_get_client_ticket
-
Input parameters:
-
caller_token -- Token for calling server.
-
conv_token -- Conversation identifier.
-
server_name -- Name of target server.
-
ticket_req -- = 1 if both ticket and authenticator are required,
= 0 if only authenticator is required.
-
Output parameters:
-
ticket -- Client's ticket for target server (null if ticket_req = 0,
unless the previous ticket has expired).
-
authent -- Authenticator.
-
status -- Completion status.
-
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.
-
Notes on implementation on top of DCE security facilities:
-
If only an authenticator is required:
-
Get the client ticket and conversation key identified
by conv_token from the key manager.
-
If the client ticket has expired:
-
Get the client PTGT and PS key
identified by conv_token from the key manager.
-
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.
-
Pass the client ticket to the key manager
for storage under conv_token.
-
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.
-
Encrypt the authenticator in the new conversation key.
-
Otherwise:
-
Get the conversation key, client PTGT, and PS key
identified by conv_token from the key manager.
-
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.
-
Pass the client ticket to the key manager for storage under conv_token.
-
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.
-
Encrypt the authenticator in the new conversation key.
Functions for authorized callers only
Trusted login
-
Function name:
edb_trusted_login
-
Input parameters:
-
caller_token -- Token for calling client.
-
userid -- Local userid.\*(f!
A name known to the local operating system.
-
Output parameters:
-
login_context -- Pointer to user's login context.
-
status -- Completion status.
-
Description:
This function is called by a trusted client to log a user in to DCE.
-
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.
-
Check that the caller is authorized.
-
Obtain the system id (machine principal id) of the local system.
-
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.
-
Request a ticket-granting ticket (TGT)
for the principal from the DCE security server.
-
Get the local user's key from the local registry.
-
Decrypt the TGT envelope with the key. The envelope contains,
in addition to the TGT, an associated conversation key.
-
Request a PTGT for the principal from the DCE security server.
-
Decrypt the PTGT envelope with the TGS conversation key.
-
Set up a login context for the user.
Trusted logout
-
Function name:
edb_trusted_logout
-
Input parameters:
-
caller_token -- Token for calling client.
-
Input-output parameters:
-
login_context -- Pointer to user's login context.
-
Output parameters:
-
status -- Completion status.
-
Description:
This function is called by a trusted client to log a user out of DCE.
-
Notes on implementation on top of DCE security facilities:
-
Purge the user's login context.
-
Purge the user's credentials cache.
Communications Integrity
Functions for general callers
Build verifier
-
Function name:
edb_build_verifier
-
Input parameters:
-
caller_token -- Token for calling client or server.
-
length -- Length of data.
-
data -- Pointer to data to be sent.
-
conv_token -- Conversation identifier.
-
verifier -- Pointer to buffer for verifier.
-
Output parameters:
-
status -- Completion status.
-
Description:
This function is called by a client or a server to build an
integrity verifier for data to be sent.
-
Notes on implementation on top of DCE security facilities:
-
Compute an MD5 digest over the input data.
-
Get the conversation key identified by conv_token
from the key manager.
-
Encrypt the digest using DES in cipher block chaining mode to
give the verifier.
Check verifier
-
Function name:
edb_check_verifier
-
Input parameters:
-
caller_token -- Token for calling client or server.
-
length -- Length of data.
-
data -- Pointer to data received.
-
verifier -- Verifier received.
-
conv_token -- Conversation identifier.
-
Output parameters:
-
status -- Completion status.
-
Description:
This function is called by a client or a server to check
the integrity of data received.
-
Notes on implementation on top of DCE security facilities:
-
Compute an MD5 digest over the input data.
-
Get the conversation key identified by conv_token
from the key manager.
-
Encrypt the digest using DES in cipher block chaining mode to
give a verifier.
-
Compare this verifier with the verifier received.
Communications Confidentiality
Functions for general callers
Encrypt data
-
Function name: edb_encrypt_data
-
Input parameters:
-
caller_token -- Token for calling client or server.
-
length -- Length of data.
-
data -- Pointer to data to be encrypted.
-
conv_token -- Conversation identifier.
-
enc_length -- Length of buffer for encrypted data.
-
enc_data -- Pointer to buffer for encrypted data.
-
Output parameters:
-
status -- Completion status.
-
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.
-
Notes on implementation on top of DCE security facilities:
-
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.
-
Get the conversation key identified by conv_token from the key
manager.
-
Encrypt the checksum followed by the input data
using DES in cipher block chaining mode to give enc_data.
Decrypt data
-
Function name:
edb_decrypt_data
-
Input parameters:
-
caller_token -- Token for calling client or server.
-
length -- Length of data.
-
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.
-
conv_token -- Conversation identifier.
-
dec_length -- Length of buffer for decrypted data.
-
dec_data -- Pointer to buffer for decrypted data.
-
Output parameters:
-
status -- Completion status.
-
Description:
This function is called by a client or a server to decrypt data
received and check its integrity.
-
Notes on implementation on top of DCE security facilities:
-
Get the conversation key identified by conv_token
from the key manager.
-
Decrypt the data received to give dec_data.
-
Separate the checksum from the body of the data.
-
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.
-
Compare the checksum with the checksum received.
GLOSSARY
-
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.
-
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).
-
Envelope
An encrypted data structure.
-
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 | |
|