OSF DCE Application Development Guide--Introduction and Style Guide

Security

under which they run and make this the default login context.

The principal name speciﬁed to rpc_binding_set_auth_info( ) establishes the principal

for which Kerberos service tickets will be requested for RPCs on the binding handle. An

application making RPC calls may or may not care about who the server principal is.

The client may be satisﬁed to call any server that provides the service it wants, or the

client may need to trust the server and thus require a trusted server principal identity.

Typically, a client learns the principal identity of a server by calling

rpc_mgmt_inq_server_princ_name( ). If the client is willing to call any server, the

returned principal name may be passed to rpc_binding_set_auth_info( ) without further

checks. If the client must trust the server, then the client needs to check the returned

principal identity against a list of (one of more) acceptable values. The client needs to

obtain this list by some application-speciﬁc means.

Note that it is not the call to rpc_mgmt_inq_server_princ_name() or any subsequent

checks on the returned name that actually authenticates the server to the client. A

malicious server could certainly arrange to return a false principal name. However, a

false name would be useless for authentication since the false server would not have

access to the secrets (keys) of this identity. However, the client does need to protect its

list of acceptable server identities to prevent a malicious server from modifying the list to

include its own identity.

3.3.5 Managing Keys

An application that wishes to perform the server side of the Kerberos protocol exchange

is principally concerned with managing its keys. Keys are normally stored in keytab

ﬁles which must be in the local host ﬁle system. The server needs local system

permission to read and write them, and they must be protected from any access by other

local identities.

Note: Keytab ﬁles are normally created by administrative action. Be aware that

the local identity or the process running rgy_edit determines the initial

local ownership of ﬁles created by ktadd.

This means that the server needs its own local identity too, to correspond to its DCE

identity. Keytab ﬁles should be owned by this local identity. The programmer or

installer must arrange for the server to run under this local identity, and only a locally

privileged user should have execute permission for the server. On UNIX systems this

can be arranged by having the server run setuid() to the chosen local identity and giving

execute permission only to speciﬁc local users.

Because the degree of integration between local and DCE login varies with DCE

implementations, it is difﬁcult to give more general advice about local identities. As the

following paragraphs explain, however, it is generally not a good idea for the server to

run with the DCE identity of a human user. If DCE and local identities are the same, the

same guideline must be applied to local identities. That is, the server’s local identity

should not be that of a human user.

When a server is initialized, it will get its key from its keytab ﬁle. The keys installed in

keytab ﬁles should not be tied to some human readable password: that is, they should be

124246 Tandem Computers Incorporated 3−9