OSF DCE Application Development Guide--Core Components

Authentication
service of interest; in this case, it is the Privilege Service.
2. Upon receiving the request for a TGT, the Authentication Service obtains the
user’s secret key from the Registry database (where the secret keys of all
principals in the cell are stored). Using its own secret key, the Authentication
Service encrypts the user’s identity, along with a conversation key, in a TGT. The
Authentication Service seals the TGT in an ‘‘envelope’’ that is encrypted using
the user’s secret key. The envelope also contains the same conversation key that is
encrypted in the TGT, and is returned to the client.
3. When the TGT envelope arrives, the login tool prompts the user for the password
and invokes sec_login_valid_and_cert_ident(). This call passes the password to
the local Security runtime library. The Security runtime derives the user’s secret
key from the password, and uses it to decrypt the envelope. (If the user enters the
wrong password, the envelope is undecryptable.) The envelope reveals the
conversation key, but the Security runtime cannot decrypt the TGT, since it does
not know the Authentication Service’s secret key. (A validated TGT is the
principal’s certificate of identity.)
Note: One of the functions of sec_login_valid_and_cert_ident() is to
demonstrate that the Authentication Service knows the key of the host
computer at which the principal is logging in (a server pretending to be the
Security server is unlikely to know the host’s key). How this is
accomplished is not illustrated here, but is explained in Chapter 29.
Having acquired the user’s Ticket-Granting Ticket, the login program then proceeds
with Part 2 of the authentication procedure (described in the following section entitled
"How the Client Obtains a Privilege-Ticket-Granting Ticket".)
23.2.1.2 How the Client Obtains a Privilege-Ticket-Granting Ticket
This section describes the acquisition, by the Security Client, of the user’s Privilege-
Ticket-Granting Ticket. Acquisition of the user’s PTGT is the second of the two parts of
DCE user authentication.
From this point on, the client principal uses four different conversation keys to talk with
other principals. Use of multiple short-lived keys makes an attacker’s task far more
difficult: there are more encryption keys to discover and less time in which to "crack"
them.
Note: Refer to Figure 23-4 as you read the following steps.
1. When the Security client runtime has succeeded in decrypting the envelope, the
API calls a network layer interface that requests a Privilege-Ticket Granting
Ticket (PTGT) from the Privilege Service. For a PTGT to be granted, however,
the user must first acquire a ticket to talk to the Privilege Service, which is a
principal distinct from the Registry and Authentication Service. The Security
runtime therefore requests such a ticket from the Authentication Service. The
Security runtime encrypts this request using the conversation key it learned when
it decrypted the TGT envelope.
124245 Tandem Computers Incorporated 23−13