Red Hat Security: Identity Management and Authentication
Describe the Kerberos protocol.
Describe the Kerberos protocol components.
Explain the Kerberos authentication process.
Kerberos is a centralized authentication protocol created by MIT. Kerberos is designed to provide secure authentication to services over insecure networks; passwords are never sent across the network, encryption keys are not directly exchanged between clients and services and applications can authenticate each other without user intervention. This authentication is achieved by the use of tickets, which allow nodes to prove their identity securely over insecure networks.
A Kerberos client sends a ticket request to the Key Distribution Center (KDC). The KDC creates a ticket-granting ticket (TGT) and uses the client's password to encrypt the ticket, and then sends the ticket back to the client. The client decrypts the TGT using its own password. When the TGT is successfully decrypted by the client it becomes proof of the client's identity.
Kerberos is one of the most successful and mature protocols to have emerged. Now at version 5, it provides benefits such as Single Sign-on (SSO), no passwords sent over communication channels, mutual authentication, and allowing authentication between unrelated entities by operating as a trusted third party. The Kerberos protocol v5 is defined in RFC4120.
The Kerberos authentication process uses the following common terms:
- Authentication Service (AS)
The AS validates that a user is present in the Kerberos database.
- Ticket Granting Service (TGS)
The TGS provides an authenticated user with a Ticket Granting Ticket.
- Ticket Granting Ticket (TGT)
A TGT is an encrypted authentication file that contains client information and a session key. The ticket is only valid for a limited time.
- Session Ticket
A session ticket is a small, encrypted authentication file with a limited validity period, used to encrypt communication between two endpoints.
- Key Distribution Center (KDC)
The Key Distribution Center is the Kerberos server running the AS and TGS services.
- Realm
The name of a Kerberos domain. The realm name is usually an uppercase version of the domain name.
- Principal
An identity that can be assigned a ticket. A principal uses the following format: primary[/instance]@REALM.
- Ticket
A piece of encrypted data representing an authenticated state, also known as a credential. A ticket can be a Ticket Granting Ticket or a session ticket.
- Symmetric key
A key used to encrypt and decrypt a payload.
- Advanced Encryption Standard (AES)
The Advanced Encryption Standard protocol replaced Data Encryption Standard (DES) as the preferred symmetric key protocol.
- Asymmetric keys
A pair of keys; one is used to encrypt and the other is used to decrypt.
- Keytab
A file containing Kerberos credentials.
- Credential Cache
A credential cache (
ccache) stores Kerberos credentials provided that the credential remains valid and the user's session exists. This enables you to authenticate against a service multiple times without contacting the KDC every time.
Kerberos is the core protocol in IdM, providing a single sign-on (SSO) capability for IdM users, and many other features. SSO gives users the ability to transparently authenticate to multiple services on-demand without providing a password for the lifetime of their Kerberos ticket.
In Kerberos terminology a principal is an identity that is unique and that can be assigned Kerberos tickets.
Principals components are separated by a separator, usually /.
The last of the principals components is the realm that is separated from the rest by the realm separator which is generally @.
If the realm component is not present the principal is assumed to be on the default realm.
A principal is composed of three parts:
Primary: The first part of the principal. For a user is the username, for a host is the word host.
Instance: An optional string that qualifies the primary. The primary is separated from the instance by a slash. For users, the instance is usually null, but it can be used to create additional principals.
Realm: The Kerberos realm, usually is a domain name in uppercase letters.
In a Kerberos system, all targets involved in authentication (users, hosts, and services) are represented by a principal.
The demo user might have a principal called demo@EXAMPLE.COM.
A user might have additional credentials, qualified with an instance name, such as demo/admin@EXAMPLE.COM, which is used for administrative tasks.
A host principal uses host as the primary, fully qualified hostname for the instance; for example, host/server01.example.com@EXAMPLE.COM.
The primary for service principals is usually a known service such as NFS, HTTPD, or LDAP.
The instance would be set to a DNS name resolvable to the hosts providing the service.
The service principal for an example corporate payroll system could be HTTP/payroll.example.com@EXAMPLE.COM.
Kerberos principals can be managed directly either by the kadmin and kadmin.local commands.
The kadmin command uses Kerberos to authenticate and kadmin.local works directly on the KDC database.
To create a principal, use the add_principal option.
[root@host ~]#kadmin.local -x ipa-setup-override-restrictions add_principal \-pw principalexample99 example@LAB.EXAMPLE.COM
To modify a principal, use the modify_principal option.
[root@host ~]# kadmin.local modify_principal -maxrenewlife 10d testReview the kadmin man page for available options.
To delete a principal, use the delete_principal option.
Use the -x ipa-setup-override-restrictions option to override the strict local IdM security restrictions.
The following example deletes the example principal.
[root@host ~]#kadmin.local -x ipa-setup-override-restrictions \delete_principal example
A keytab file is used to store multiple principal keys on the local file system.
Because keys exist for each encryption type, and previous key versions are kept, you might find multiple keys for a principal in each keytab.
Because users are required to type in their passwords when they log in, they have no need of a keytab file.
However, hosts and services need credentials when they start, so storing their credentials locally allows them to start without human intervention.
To see the keys currently stored in a keytab file, use the klist command with the -k option.
You can pass the -e option to see the encryption type for each key.
[user@host ~] klist -ke /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- ----------------------------------------------------------------------
2 host/idm.lab.example.com@LAB.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
2 host/idm.lab.example.com@LAB.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
2 host/idm.lab.example.com@LAB.EXAMPLE.COM (des3-cbc-sha1)
2 host/idm.lab.example.com@LAB.EXAMPLE.COM (arcfour-hmac)
2 host/idm.lab.example.com@LAB.EXAMPLE.COM (camellia128-cts-cmac)
2 host/idm.lab.example.com@LAB.EXAMPLE.COM (camellia256-cts-cmac)The following diagram shows the authentication flow for a user logging in and authenticating to a service. The flow in the diagram is not in time order, nor does it cover every aspect of the interactions.
 |
| The AS on the KDC maintains account information for all security principals in the realm, including a cryptographic key derived from a user's login password. For services, which have no login password, the key is dynamically generated and stored in the service's keytab file. These credentials were created and stored by the KDC before step 1 in this figure. Each principal's cryptographic key is a shared secret between the KDC and only that principal. To use a Kerberos-enabled service, the user first sends a request to the AS. |
| To allow TGS access to the user, the AS encrypts one copy of a newly generated session key with the user's shared password key. A second copy is combined with the user's identity, and encrypted with the TGS' shared generated key to become a TGT. Both copies are sent to the user, but only the copy encrypted with user's shared key can be decrypted to retrieve the session key. The second copy, the TGT, can be decrypted only by the TGS. |
| The user encrypts their identity with the TGS session key. The encrypted identity and the encrypted TGT from the AS are then sent to the TGS along with a request to access a particular service. The TGS decrypts the TGT using its private key, and obtains the session key and the requesting user's identity. The TGS uses the session key to decrypt the identity sent by the user. The identity sent by the user and the identity encrypted in the TGT by the AS are then compared. If they match, then the user's TGT is considered valid and the service request is processed. The same TGT can be used for any future service requests until it expires; the user must then return to the AS to request a new TGT. |
| The TGS generates a new session key to be used in a manner similar to that just described, but this time it allows the user to access the requested Kerberos-enabled service. The TGS encrypts one copy of this service session key with the user's shared password key. A second copy is combined with the user's identity and encrypted with the Kerberos-enabled service's shared generated key. Both copies are sent to the user, but only the copy encrypted with the user's shared key can be decrypted, retrieving the service session key. The second copy can be decrypted only by the Kerberos-enabled service. |
| The user encrypts their identity with the service session key, and then sends both the encrypted identity and the encrypted service session key to the Kerberos-enabled service. The service session key is decrypted first, using the Kerberos-enabled service principal's shared key from a keytab file, and also retrieves the requesting user's identity. The Kerberos-enabled service uses the service session key to decrypt the identity sent by the user, and then compares the two identities. If they match, then the user's request is valid and the service request is processed. |
| The service session key can be used to encrypt data responses until its expiration is reached. The user then returns to the TGS to request a new service session key, using an unexpired TGT for proof of identity without returning to the AS for re-authentication. |
Users authenticated with the Kerberos protocol get a ticket from the Key Distribution Center (KDC), Kerberos achieves SSO by using this ticket to access multiple systems without having to send credentials over the network.
Configuring Firefox to Use Kerberos for Single Sign-on
To configure Firefox to use Kerberos for SSO to intranet sites and other protected websites, it must first be configured to send Kerberos credentials to the appropriate KDC. Firefox requires a valid Kerberos ticket to use SSO.
To generate a Kerberos ticket, authenticate to IdM by using the kinit command.
[user@host ~]$kinitPassword for user@EXAMPLE.COM:userpassword
To configure Firefox to use Kerberos for SSO:
In the address bar of Firefox, type
about:configto display the list of current configuration options.In the field, type
negotiateto restrict the list of options.Double-click the
network.negotiate-auth.trusted-urisentry.In the text box, enter the name of the domain against which to authenticate, including the preceding dot (
.) character. For multiple domains, enter them in a comma-separated list.
References
For more information about Kerberos, refer to Kerberos: An Authentication Service for Computer Networks
For more information about Kerberos, refer to RFC4120: The Kerberos Network Authentication Service (V5)
For more information, refer to the The role of the IdM KDC section in the Managing Kerberos ticket policies chapter in the Managing IdM users, groups, hosts, and access control rules guide at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/managing_idm_users_groups_hosts_and_access_control_rules/index#role-of-idm-kdc_managing-kerberos-ticket-policies
