Overview
DES vs 3DES Key Type Settings
| DES vs 3DES Key Type Settings |
| In the processes outlined above, what happens if the user principal and |
| the service principal do not use the same key type? The answer is - the |
| process continues as described. Here’s why. |
| There is no step in which the client or the service accepts a message |
| encrypted by the other’s key. The Kerberos Server acts as the only |
| trusted party. Both the client application and the service share a secret |
| with only the server. |
| The authenticator data that must be encrypted or decrypted by both the |
| service and the client is encrypted in session keys. The server sends the |
| required session keys to the client and service in packets that are |
| encrypted with their respective keys. The Kerberos Server determines |
| the strongest encryption allowed for the session key by checking the key |
| type settings for the user and service principals. If both have a 3DES key |
| stored in the database, the session key type that is returned is of type |
| 3DES. If only one has a 3DES key and the other has a DES key, then the |
| session key that is returned is of type DES. |
| Note that the server will never return a session key in the service ticket |
| packet that uses stronger encryption than the session key included with |
| a TGT packet. If a user principal has both a 3DES and DES key, and uses |
| the DES key to obtain a TGT - all service tickets obtained using this TGT |
| will contain DES session keys. |
| The krbtgt/<REALM NAME> is the |
WARNING | |
| a reserved principal that is automatically created when a realm |
| is added to the database. The krbtgt/<REALM NAME>principal |
| must be assigned a key type or default keys issued by the |
| Kerberos Server will use the 3DES encryption type. |
|
|
32 | Chapter 1 |