OSF DCE Application Development Guide--Core Components

DCE Security Service
proceeds with preparation of the user’s Ticket-Granting Ticket.
4. The Authentication Service then prepares the user’s Ticket-Granting Ticket,
encrypts it using conversation key 2 (which it received from the client Security
Runtime) and returns the encrypted TGT to the client.
5. The client Security Runtime decrypts the reply from the Authentication Service
using conversation key 2, obtains the user’s Ticket-Granting Ticket, and it
becomes part of the login context.
Note the following security safeguards inherent in the structure of this protocol:
• All network transmissions between Security client and Authentication Service are
encrypted using strong random keys. All plaintext transmissions (which are
vulnerable to off-line attacks) are double-encrypted, placing even off-line decryption
attempts at the outer limits of practical possibility.
• The timestamp and conversation key 2 are encrypted using the user’s secret key,
which is derived from the user’s password. This enables the Authentication Service
to verify that the requesting client knows the user’s password. (It does this by
decrypting the package using the Registry’s copy of the user’s secret key; if the
decryption succeeds, the keys are the same, i.e., they were derived from the same
password.)
• The Authentication Service itself verifies whether the requesting client knows the
user’s password. It is therefore aware of, and can manage, persistent login failures
for a given user, eliminating passive password-guessing attacks.
• The Authentication Service’s reply is encrypted using conversation key 2, which was
provided by the client. This verifies to the client that the Authentication Service is
authentic, since, if it were not, it would not have been able to obtain from the
Registry the machine session key and user’s secret key it needed to decrypt
conversation key 2.
These safeguards provide assurance to both server and client that the entity with which
it is communicating is, in fact, what it claims to be.
Having acquired the user’s Ticket-Granting Ticket, the login program then proceeds
with Part 2 of the authentication procedure (described below in the section entitled
"How the Client Obtains a Privilege-Ticket-Granting Ticket.")
23.2.1.1.2 The Timestamps Authentication Protocol
This section describes how the DCE Authentication Service uses the timestamps
authentication protocol to provide a user with a Ticket-Granting Ticket.
(Since the timestamps protocol is largely identical to the DCE1.0 protocol, which is
fully explained in the next section, this section describes only the differences between
the two.)
The timestamps protocol proceeds exactly as the DCE1.0 protocol described in the
following section, with these additions:
23−10 Tandem Computers Incorporated 124245