Kerberos internals
Realm: An authentication administrative domain. Each administrative domain has its own kerberos database. Database contains information about users, hosts and services. Authentication between user and service in different realms can take place with trust relationship known as cross-authentication. User/services share a secret (password/key) with authentication server in the same realm. Traditionally, kerberos realms match DNS names and are written in capital letters.
Kerberos provides ticket and ticket session key. Together they are called credentials.
Principal: name or type of service/instance (specific machine offering the service)@realm_name. Principal is a set of specific entity to which credentials may be assigned. Principals are allocated to user or service or host. Used to refer to entries in authentication server database. Service principals are normally of the form, Service/Hostname@REALM (e.g imap/mail.example.com@EXAMPLE.COM). Some principals do not refer to users or hosts but play a role in operation of authentication system e.g krbtgt/REALM@REALM
Service Key: Known to both service and kerberos, stored in database. On server, these keys are stored in keytab files.
Keytab: A key tab file contains keys. Host/service used this file.
Kinit program can be used to get ticket. Ticket and session key are encrypted by user password, before returning to the user. Kinit stores the ticket in credential cache on the client machine.
Tickets are issued by authentication server and are encrypted using the secret key of the service they are intended for. As secret key of service is only shared between authentication server and app server, client can not read the ticket. A ticket contains user and service principal, IP address of client machine, ticket start and expiration time along with session key. Client in addition to the ticket, also encrypts another packet containing user principal and time stamp with the session key. This packet is called authenticator and is valid for 2 minutes. Replay cache on the application and AS/TGS server rejects duplicate authenticator packets. Tickets and session key is stored in credential cache at client end.
* Some of the insecurities that kerberos avoids is password storage on clients (AS/client generates secret key based on user password and salt), authentication information stored at multiple points, password over the network, multiple logins to applications etc.
* Kerberos is strict about DNS reverse resolution, so reverse resolution of server IP address should point back to FQDN or host part in service principal.
* Kerberos uses symmetric encryption. string2key function in kerberos converts user password into an encryption key suitable for the type and strength of encryption algorithm in use. Kerberos 5 supports salted password, meaning a string is concatenated with the unencrypted password before applying string2key function. Both kerberos clients and services share a secret with KDC. For users, it is the key derived from their password, for services it is secret key set by the administrator. User and services shares a key with each other, known as the session key. Role of session key listed in a ticket is fundamental in kerberos transactions.
Authentication server = Key distribution center (KDC) consists of three parts, authentication server (AS), ticket granting server (TGS) and database. Database is encrypted with master key associated with principal, K/M@REALM. Database backup or replication is encrypted with same key. Entries in the database are made up of:
1) Entry principal
2) Entry encryption key and its version
3) validity of ticket for the entry
4) No of times ticket can be renewed
5) Password expiration date
6) Expiration date of the principal.
Client request for service tickets after having being issued a valid ticket granting ticket (TGT). TGT is issued by authentication server, whereas service tickets are issued by ticket granting server.
* Application server does not communicate directly with the KDC. User tickets are forwarded to the server from the client. Sequence of kerberos authentication is as follows:
Client to Authentication server: initial request by kinit (AS_REQ), request is unencrypted and contains user and service principal (krbtgt/REALM@REALM for TGT request), allowed client IP list and validity lifetime
Authentication server to client: contains TGT (encrypted with TGS secret key) and session key (AS_REP). User and service principal in KDC database. AS creates a random session key, which serves as a shared secret between client and TGS. Along with TGT, AS also sends information such as principals, allowed IP and lifetime (encrypted with user secret key) to the client. The client asks user to enter password, password is concatenated with salt, string2key function applied to get user secret key. This key should be able to decrypt AS provided information. Pre-authentication forces client to prove its identity, by sending request encrypted with user long term key, before it can be provided the service ticket.
Client to TGS: requests service ticket by sending TGT and authenticator, encrypted with session key (TGS_REQ)
TGS to client: Sends service ticket, encrypted with service's secret key, service session key, encrypted by previous session key generated by AS (TGS_REP)
Client to application server: Sends request by sending service ticket, authenticator, encrypted with service session key (AP_REQ). This request is not standard but varies with application. Server checks if user principal in request matches with that in service ticket.
Application server to client: Only, if mutual authentication is required
* Trust relation between realms can be direct, transitive and hierarchical. KDCs in two realms share keys in trust relationship. There is a remote TGT of the form krbtgt/B@A and is associated with a secret key. Transitive trust reduces the number of keys required to share between KDCs of different realms.
Ticket flags:
I = Initial
R = Renewable
Keys
Service secret key = Only known to service and KDC
User secret key = Only know to user (as generated from user password) and KDC
session key between client and application server
session key between client and TGS
Kerberos provides ticket and ticket session key. Together they are called credentials.
Principal: name or type of service/instance (specific machine offering the service)@realm_name. Principal is a set of specific entity to which credentials may be assigned. Principals are allocated to user or service or host. Used to refer to entries in authentication server database. Service principals are normally of the form, Service/Hostname@REALM (e.g imap/mail.example.com@EXAMPLE.COM). Some principals do not refer to users or hosts but play a role in operation of authentication system e.g krbtgt/REALM@REALM
Service Key: Known to both service and kerberos, stored in database. On server, these keys are stored in keytab files.
Keytab: A key tab file contains keys. Host/service used this file.
Kinit program can be used to get ticket. Ticket and session key are encrypted by user password, before returning to the user. Kinit stores the ticket in credential cache on the client machine.
Tickets are issued by authentication server and are encrypted using the secret key of the service they are intended for. As secret key of service is only shared between authentication server and app server, client can not read the ticket. A ticket contains user and service principal, IP address of client machine, ticket start and expiration time along with session key. Client in addition to the ticket, also encrypts another packet containing user principal and time stamp with the session key. This packet is called authenticator and is valid for 2 minutes. Replay cache on the application and AS/TGS server rejects duplicate authenticator packets. Tickets and session key is stored in credential cache at client end.
* Some of the insecurities that kerberos avoids is password storage on clients (AS/client generates secret key based on user password and salt), authentication information stored at multiple points, password over the network, multiple logins to applications etc.
* Kerberos is strict about DNS reverse resolution, so reverse resolution of server IP address should point back to FQDN or host part in service principal.
* Kerberos uses symmetric encryption. string2key function in kerberos converts user password into an encryption key suitable for the type and strength of encryption algorithm in use. Kerberos 5 supports salted password, meaning a string is concatenated with the unencrypted password before applying string2key function. Both kerberos clients and services share a secret with KDC. For users, it is the key derived from their password, for services it is secret key set by the administrator. User and services shares a key with each other, known as the session key. Role of session key listed in a ticket is fundamental in kerberos transactions.
Authentication server = Key distribution center (KDC) consists of three parts, authentication server (AS), ticket granting server (TGS) and database. Database is encrypted with master key associated with principal, K/M@REALM. Database backup or replication is encrypted with same key. Entries in the database are made up of:
1) Entry principal
2) Entry encryption key and its version
3) validity of ticket for the entry
4) No of times ticket can be renewed
5) Password expiration date
6) Expiration date of the principal.
Client request for service tickets after having being issued a valid ticket granting ticket (TGT). TGT is issued by authentication server, whereas service tickets are issued by ticket granting server.
* Application server does not communicate directly with the KDC. User tickets are forwarded to the server from the client. Sequence of kerberos authentication is as follows:
Client to Authentication server: initial request by kinit (AS_REQ), request is unencrypted and contains user and service principal (krbtgt/REALM@REALM for TGT request), allowed client IP list and validity lifetime
Authentication server to client: contains TGT (encrypted with TGS secret key) and session key (AS_REP). User and service principal in KDC database. AS creates a random session key, which serves as a shared secret between client and TGS. Along with TGT, AS also sends information such as principals, allowed IP and lifetime (encrypted with user secret key) to the client. The client asks user to enter password, password is concatenated with salt, string2key function applied to get user secret key. This key should be able to decrypt AS provided information. Pre-authentication forces client to prove its identity, by sending request encrypted with user long term key, before it can be provided the service ticket.
Client to TGS: requests service ticket by sending TGT and authenticator, encrypted with session key (TGS_REQ)
TGS to client: Sends service ticket, encrypted with service's secret key, service session key, encrypted by previous session key generated by AS (TGS_REP)
Client to application server: Sends request by sending service ticket, authenticator, encrypted with service session key (AP_REQ). This request is not standard but varies with application. Server checks if user principal in request matches with that in service ticket.
Application server to client: Only, if mutual authentication is required
* Trust relation between realms can be direct, transitive and hierarchical. KDCs in two realms share keys in trust relationship. There is a remote TGT of the form krbtgt/B@A and is associated with a secret key. Transitive trust reduces the number of keys required to share between KDCs of different realms.
Ticket flags:
I = Initial
R = Renewable
Keys
Service secret key = Only known to service and KDC
User secret key = Only know to user (as generated from user password) and KDC
session key between client and application server
session key between client and TGS
posted by Usman Wahid at
6:06 PM
0 Comments:
Post a Comment
<< Home