How the Client Obtains a TGT for the User

Authentication protocols used by DCE security clients and servers to obtain TGTs for users, which is the first part of the user-authentication process, are:

· The public key protocol, which provides the highest level of security

· The third-party protocol, which is less secure than public key protocol

· The timestamps protocol, which is less secure than the third-party protocol

· The DCE Version 1.0 protocol, which is the least secure of the three and is provided solely to enable DCE Version 1.1 security servers to process requests from pre-DCE Version 1.1 clients

The protocol used by the security client when it makes a login request to the authentication service is determined as follows:

1. Pre-DCE Version 1.1 clients always use the DCE Version 1.0 protocol.

2. DCE Version 1.1 clients always use the third-party protocol, unless the host machine's session key, which the client uses to construct the request, is unavailable. It then uses the timestamps protocol.

3. DCE Version 1.2.2 clients always attempt to use the public key authentication protocol. If a client is unable to use the protocol, the client reverts to DCE Version 1.1 behavior.

The protocol used by the authentication service to respond to the client is determined by the following:

· The protocol used by the client making the login request

· The value of any pre_auth_req ERA attached to the requesting principal

The authentication service always attempts to reply by using the same protocol used by client making the request, unless the value of the ERA forbids it to do so. (See the discussion of DCE Version 1.1 authentication in the OSF DCE Administration Guide - Core Components for more detailed information on how security clients and the authentication service determine which protocol to use.)

For a general discussion of the security aspects of these protocols, and of security administration and security ERAs, see the OSF DCE Administration Guide - Core Components . The following subtopics explain how the three protocols operate.

The Public Key Authentication Protocol

Public key authentication protocol works via public and private key-pairs. A user's identity is proven to the DCE Key Distribution Center (KDC) through a signature in the user's private authentication key. The KDC verifies the request through the user's authentication public key, which must be contained in the DCE registry. If the request is verified, the KDC replies with a TGT that is first signed by the KDC using its own private authentication key, and then is encrypted by the KDC using the client's key encipherment public key, which must be stored in the DCE registry. Because the KDC does not know the user's private keys, a compromise of the KDC cannot reveal the private keys. Therefore, public key users will not have any identifying information exposed to an intruder. This method of public and private key pair usage constitutes the public key protocol.

The public key protocol invokes routines sec_login_validate_identity( ), sec_login_valid_and_cert_ident( ), and sec_login_validate_first( ) as follows:

1. The user logs in.

2. The client process sends a message to the KDC. The message consists of a timestamp and nonce signed by the client's private digital signature key. An optional certificate of the client can also be sent along.

3. The KDC checks the timestamp and signature of the client's message. If the information is valid, the KDC sends a reply key to the client. The reply consists of a message signed by the KDC's digital signature key and then encrypted by the client's key encipherment key. The reply key is for encrypting the encrypted portion of the Kerberos KRB_AS_REP message, which includes the symmetric session key associated with the TGT. The session key used in association with the TGT is returned in the standard EncKDCRepPart field of the KRB_AS_REP message.

If the KDC is unable to authenticate the user's supplied public key data, the KDC returns an error indicating why the authentication failed and whether the user is required to use the public key authentication protocol. The KDC determines this from the pre_auth_req ERA attached to the user principal.

If the public key login attempt fails, the sec_login code instead falls back to the use of existing password-based authentication unless the KDC error information indicates that the principal is required to use public key login authentication. Preventing fall back is done by giving each principal a pre_auth_req ERA value of PADATA_ENC_PUBLIC_KEY.

Authentication information is transmitted as data types:

· KRB5_PADATA_PUBKEY_REQ

· PADATA_ENC_PUBKEY_REP

4. The client checks the signature on the reply to make sure it is from the KDC. The sesion key can be decrypted only by the legitimate client that possesses the private key needed to decrypt. The client then uses the TGT and associated session key.

Storage of the Private Key

Private key information is stored either in a local file or by the DCE private key storage server (PKSS). If the principal's DCEPKPrivateKeyStorage ERA value is not set, the login program assumes the private key is stored in a local file. If the principal's DCEPKPrivateKeyStorage ERA value is set, the login program obtains the private key from the private key storage mechanism associated with the UUID contained in the ERA. The currently supported storage mechanisms and their associated UUID's are the following:

· Local file - The UUID is 8687c5b8-b01a-11cf-b137-0800090a5254.

· Private key storage server (PKSS) - The UUID is 72053e72-b01a-11cf-8bf5-0800090a5254.

· Registry Database - The UUID is adb48ed4-e94d-11cf-ab4b-08000919ebb5. (This mechanism is supported for internal security server purposes only.)

The PKSS stores private keys in records that have the following information:

· The user's principal name.

· The user's public key.

· The key version of the user's public key (key v.n).

· The application domain. (Currently, private keys are used only in the context of a DCE login.)

· Key usage flags. (Currently, private keys are used only for authentication and for key encipherment.)

· Password hash value 2 (H2) derived from the user's password.

· The user's private key encrypted under the user's password hash value 1 (H1).

The PKSS cannot directly access the user's private key because it does not have the user's password H1 value. An ACL protects user records from unauthorized access, allowing access to only the sec_admin principal.

The following two descriptions depict the initial message exchange between the login client and the PKSS, and the second (final) exchange in which the PKSS returns the private key to the client.

Client Initiation of Private Key Acquisition from PKSS

The client DCE login program begins the process of key acquisition from the PKSS. Refer to the following figure as you read the following steps.

1. The login client sends a message to the PKSS that consists of the following components:

· The user's principal name.

· The application domain.

· Key usage flags.

· The key version number (key v.n).

· An exponentiated Diffie-Hellman value (S to the c power) used for establishing a Diffie-Hellman key.

· An algorithm list (alg list), which is a list of secret key encryption algorithms supported by the client (currently only DES). The client and the PKSS use this algorithm with the Diffie-Hellman key and the session key.

2. Upon receipt of this message from the login client, the PKSS generates a Diffie-Hellman value of its own (S to the s power). Using this value along with the client's Diffie-Hellman value, the PKSS computes a Diffie-Hellman key.

The PKSS determines whether it supports any of the algorithms listed in the client message. If so, it can communicate securely with the client and the PKSS selects one of the supported algorithms for use. (Currently, OSF DCE clients and servers support only DES.)

3. The PKSS generates a random session key and a nonce (N to the s power). The session key will be used to encrypt messages between the client and server. The PKSS encrypts the nonce (N to the s power) with the session key, then encrypts the session key with the user's password H2 value taken from the user record.

4. The PKSS computes a hash on the algorithm list provided by the client. It encrypts both the hashed algorithm list and the encrypted session key (see step 3) under the Diffie-Hellman key generated in step 2.

5. The PKSS composes and sends the client a message consisting of

· The nonce (N to the c power) encrypted under the random session key.

· The session key encrypted by the user's password H2 value and then encrypted under the Diffie-Hellman key.

· The hashed algorithm list further encrypted under the Diffie-Hellman key.

· The algorithm to be used for the session key. (The algorithm is chosen from the client's algorithm list.)

· The PKSS-generated Diffie-Hellman value.

6. Upon receipt, the login client extracts the PKSS-generated Diffie-Hellman value and combines it with its own Diffie-Hellman value to obtain its copy of the Diffie-Hellman key.

7. The client uses the encryption algorithm specified by the PKSS, along with its Diffie-Hellman key to obtain the hashed algorithm list and the session key (still encrypted under the user's password H2 value).

The login client computes a hash on its own algorithm list and compares it with the hashed algorithm list returned from the PKSS. The two lists must match. Otherwise, the client determines that the PKSS is invalid and returns an error.

8. The login client decrypts the session key by using H2 derived from the user's password. The client uses the session key to decrypt the PKSS-generated nonce (N to the s power). The session key will be used to authenticate the current session communications between the client and PKSS.

Note: A PKSS imposter would not know the user's password H2 value. The resulting session key would differ from the imposter's session key, preventing further communications between the client and the imposter.

9. The client composes a message encrypted under the session key. The message consists of

· The PKSS-generated nonce (N to the s power)

· A client-generated nonce (N to the c power)

· An operation identifier that indicates private key acquisition

Client Initiation of Private Key Acquisition

Client Completion of Private Key Acquisition from PKSS

The client DCE login program completes the process of key acquisition from the PKSS. Refer to the following figure as you read the following steps.

1. The client sends the PKSS the composed message encrypted under the session key (see Step 9 in the preceding discussion).

2. Upon receipt of the client message, the PKSS uses the session key to obtain the operation ID, the client-generated nonce (N to the c power), and the PKSS-generated nonce (N to the s power).

The PKSS compares the client's copy of N to the s power with its original nonce (N to the s power). A match proves the client had knowledge of the user's secret password which was needed to obtain the session key. The client used the session key to obtain N to the s power.

3. The PKSS composes a message consisting of

· The user's private key encrypted under the user's password H1 value

· The user's public key

· The key version number

· The client-generated nonce (N to the c power)

4. The PKSS encrypts this message with the session key and sends it to the client.

5. Upon receipt, the client uses the session key to obtain the user's private key (encrypted under the user's password H1 value), the user's public key, the key version number, and the client-generated nonce (N to the c power).

The client compares the PKSS's copy of Nc with its own nonce. A match proves the authenticity of the PKSS because only the true PKSS could have used the correct user password H2 value to properly encrypt the session key passed to the client in the first message.

6. The client uses its password H1 value to decrypt the private key. The client's security runtime program returns the authenticated private key to the calling routine.

Client Acquisition of Private Key from PKSS

The Third-Party Authentication Protocol

The DCE Authentication Service can use the third-party authentication protocol to provide a user with a TGT. Refer to the following figure as you read the following steps.

1. The user logs in, entering the correct user name. The login program invokes sec_login_setup_identity( ), which takes the user's principal name as one of its arguments, and sec_login_valid_and_cert_ident( ), which has the user's password as one of its arguments. The sec_login_valid_and_cert_ident( ) routine causes the security runtime to request a TGT from the authentication service of the KDS. (The client principal will later present the TGT to the TGS, to acquire service tickets to other servers.) The client's security runtime performs the following steps to construct the TGT request to the authentication service:

a. It requests, from the secval service, a random key, say conversation key 1, which the client will later use to encrypt its request to the authentication service. Two copies of conversation key 1 are passed to the client: one unencrypted and one encrypted in the machine session key (a copy of which is sealed inside the machine ticket-granting ticket, or MTGT). (In order to do this securely, the request to secval must be done over a secure local communications channel on the host machine.) It then concatenates the encrypted copy of conversation key 1 with the MTGT.

Client Acquires TGT Using Third-Party Protocol

b. It generates another random key, conversation key 2, which the authentication service will later use to encrypt the TGT it returns to the client. It then concatenates it to a timestamp string.

c. It derives, from the password input by the user, the user's secret key, a copy of which also exists in the registry service database. It then encrypts the timestamp/conversation key 2 twice: first by using the user's secret key, and then by using conversation key 1.

d. Finally, it completes constructing the authentication service request message by concatenating the encrypted conversation key 1 (obtained from secval in Step 1a) with the doubly encrypted timestamp and conversation key 1.

2. The client's security runtime then forwards the constructed request to the authentication service of the KDS. (This corresponds to the first step of the DCE Version 1.0 protocol, described in The DCE Version 1.0 Authentication Protocol, below.)

3. The authentication service receives the request and performs the following steps to verify the user and prepare the user's TGT:

a. It decrypts the MTGT (by using the KDS's secret key), and obtains the machine session key from it. (This decryption is not shown pictorially in the figure above.)

b. Using the machine session key, it decrypts the package containing conversation key 1.

c. It obtains the user's secret key from the registry service and then decrypts the doubly encrypted package containing the timestamp and conversation key 2 by using the user's secret key and conversation key 1.

If this decryption fails, the user's secret key that was used by the login program to encrypt the package differs from the one stored in the registry service, and therefore the password supplied to the login program by the user was incorrect. In this case, the user is not authenticated, and an error code is returned to the login program.

If the decryption succeeds, and if the decrypted timestamp is within an allowable clock skew (5 minutes) of the current time, the user has been authenticated (that is, the user knows the correct principal password and this isn't a replay attack), and the authentication service proceeds with preparation of the user's TGT.

4. The authentication service then prepares the user's TGT, encrypts it in the KDS's secret key, encrypts the conversation key 3 contained in the TGT (to be used later by the client to acquire service tickets) in conversation key 2, and returns this data to the client.

5. The client security runtime decrypts the reply from the authentication service by using conversation key 2, obtaining the conversation key 3 from the TGT, and it becomes part of the client's login context.

Note the following security safeguards inherent in the structure of this protocol:

· All network transmissions between the security client and the authentication service are encrypted by using strong random keys (not weak keys derived from passwords), placing even offline decryption attempts at the outer limits of practical possibility.

· The timestamp and conversation key 2 are encrypted by using the user's secret key, which is derived from the user's password (and subsequently reencrypted by using conversation key 1). This enables the authentication service to verify that the requesting client knows the user's password. (It does this by decrypting the package via the registry service's copy of the user's secret key; if the decryption succeeds, the keys are the same, that is, they were derived from the same password.)

· The authentication service actively verifies whether the requesting client knows the user's password. Contrast this with the DCE Version 1.0 protocol, where the authentication service blindly issues TGTs without requiring any evidence that the requester knows the user's password. It is therefore aware of, and can manage, persistent login failures for a given user, eliminating active password-guessing attacks.

· The authentication service's reply is encrypted by using conversation key 2, which was provided by the client. This verifies to the client that the authentication service itself is authentic since, if it were not, it would not have been able to obtain 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 each is communicating is, in fact, what it claims to be.

Having acquired the user's TGT, the login program then proceeds with the next step in the authentication procedure (described in How the Client Obtains a PTGT).

The Timestamps Authentication Protocol

This topic describes how the DCE Authentication Service uses the timestamps authentication protocol to provide a user with a TGT.

Since the timestamps protocol is largely identical to the DCE Version 1.0 protocol, which is fully explained in the next topic, this topic describes only the differences between the two.

The timestamps protocol proceeds exactly as the DCE Version 1.0 protocol described in the following topic, with these additions:

· In Step 1, the client security runtime sends to the authentication service, in addition to the user's string name, the current timestamp encrypted in the user's secret key.

· In Step 2, the authentication service, before preparing the user's TGT, verifies the user's authenticity (albeit not as strongly as in the third-party protocol) as follows:

1. It decrypts the timestamp by using the copy of the user's key it obtained from the registry service.

2. If the decryption succeeds, and the timestamp is within an allowable clock skew (5 minutes) of the current time, the user is authenticated, and the authentication service proceeds to prepare the TGT. If the decryption fails, or if the timestamp is not within the allowable clock skew, the authentication service rejects the login request.

With this protocol, the authentication service can verify the following:

· That the client login request is timely; that is, that the authentication service is communicating with the client "now'' (within the allowable clock skew)

· That the requesting client knows the user's password

The authentication service is therefore aware of, and can manage, persistent login failures for a given user, eliminating passive password-guessing attacks.

From this point, the timestamps protocol continues as the DCE Version 1.0 protocol described in the next topic, and then proceeds with the next step in the authentication procedure, described in How the Client Obtains a PTGT.

Note: Encrypted timestamps (under the name authenticators) are passed in several places in the protocols, to guarantee "fresh'' communications (within the allowable clock skew) and thereby guard against replay attacks. This has been shown explicitly in the preceding, but will be omitted in the remainder of this topic.

The DCE Version 1.0 Authentication Protocol

This topic explains how the DCE Authentication Service uses the DCE Version 1.0 protocol to authenticate a user. This protocol exists in DCE Version 1.1 solely to provide interoperability between DCE Version 1.1 servers and pre-DCE Version 1.1 clients; only pre-DCE Version 1.1 clients transmit DCE Version 1.0 login requests, and the authentication service returns DCE Version 1.0 responses only to pre-DCE Version 1.1 clients.

The DCE Version 1.0 protocol lacks the security features previously described for the third-party and timestamps protocols, hence this protocol is more vulnerable to attacks. You should keep this in mind when you are considering the inclusion of pre-DCE Version 1.1 clients in your DCE Version 1.1 cell.

The DCE Version 1.0 protocol proceeds as follows. Refer to the following figure as you read these steps.

1. The user logs in, entering the correct user name. The login tool invokes sec_login_setup_identity( ), which takes the user's principal name as one of its arguments. This call causes the client security runtime to request a TGT and passes the user's name (represented as a string, not a UUID) to the authentication service. The TGT will later be used by the client to acquire service tickets to other services; the first such usage will be to acquire a service ticket to the privilege service (see How the Client Obtains a PTGT).

Client Acquires TGT Using the DCE Version 1.0 Protocol

2. Upon receiving the request for a TGT, the authentication service obtains the user's secret key from the registry service database (where the secret keys of all principals in the cell are stored). Using its own secret key (that is, that of the KDS), the authentication service encrypts the user's identity, along with a conversation key 3 (this conversation key 3 is the same as conversation key 3 in the discussion of the third-party protocol, earlier in this topic), in a TGT. The authentication service separately encrypts a copy of conversation key 3 with the user's secret key and returns this data to the client.

3. When this data arrives at the client, the login tool prompts the user for the password and invokes sec_login_valid_and_cert_ident( ). This call passes the password to the client's security runtime library. The security runtime derives the user's secret key from the password (using a well-known algorithm), and uses it to decrypt conversation key 3. (If the user enters the wrong password, this decryption fails.) The client's security runtime cannot decrypt the TGT since it does not know the KDS secret key. The TGT is the client principal's certificate of identity - it is usable by the client precisely because the client knows the conversation key 3 carried in it.

Note: One of the functions of sec_login_valid_and_cert_ident( ) is to authenticate the authentication service itself to the host machine's login program, by demonstrating that the (purported) authentication service really knows the secret key of the host computer. (The mere fact that the purported authentication service knew the user's secret key is not convincing to the host's login program, because that purported authentication service could have been a bogus server working in league with a bogus user - the host does not trust any of these things.) The way in which this is accomplished is not illustrated here but is explained in The Login API.

Having acquired the user's TGT, the login program then proceeds with the next step in the authentication procedure, described in How the Client Obtains a PTGT.