Basic Concepts of Kerberos
Long Term Key
The KDC stores a cryptographic key known only to the security principal and the KDC. This key is used in exchanges between the security principal and the KDC and is known as a long-term key.A user's long-term key is derived from a password. On the client side, the Kerberos client on the client side workstation accepts the client's password and then converts it to a cryptographic key by passing the text of the password through a one-way hashing function.
The KDC gets its copy of client's long-term key from the respective record in its account database. When it receives a request from the Kerberos client on client's workstation, the KDC searches its database for client, pulls up the releveant account record, and takes the long-term key from a field in the record associated with he account record..
Using the TGT
1. client makes a request to the KDC.
2. KDC responds by returning a session ticket for itself (TGT, a TGT contains a copy of the session key that the service uses to communicate with the client.), and a copy of the session key that the client can use in communicating with the KDC. The TGT is encrypted in the KDC's long-term key. The client's copy of the session key is encrypted in the user's long-term key.
3. When the client receives the KDC's reply to its initial request, it uses its cached copy of the user's long-term key to decrypt its copy of the session key. It can then discard the long-term key derived from the user's password, for it is no longer needed. In all subsequent exchanges with the KDC, the client uses the session key. Like any other session key, this key is temporary, valid only until the TGT expires or the user logs off. For that reason, it is called a logon session key .
4. Before it attempts to connect to a service, the client first checks its credentials cache for a session ticket to that service.
5. If it does not have one, it checks the cache again for a TGT.
6. If it finds a TGT, the client fetches the corresponding logon session key from the cache, uses this key to prepare an authenticator, and sends both the authenticator and the TGT to the KDC, along with a request for a session ticket for the service. In other words, gaining admission to the KDC is no different from gaining admission to any other service in the domain — it requires a session key, an authenticator, and a ticket (in this case, a TGT).
7. From the KDC's point of view, TGTs allow it to shave a few nanoseconds off the turnaround time for ticket requests. The KDC looks up the user's long-term key only once, when it grants an initial TGT. For all other exchanges with this client, the KDC can decrypt the TGT with its own long-term key, extract the logon session key, and use that to validate the client's authenticator.
Reference for Key generation and key usage of a system: http://technet.microsoft.com/
Please note the information is not written by myself. This was shared by WSO2 Developer. I'm just sharing here for those who interested about knowing the basics.
The KDC stores a cryptographic key known only to the security principal and the KDC. This key is used in exchanges between the security principal and the KDC and is known as a long-term key.A user's long-term key is derived from a password. On the client side, the Kerberos client on the client side workstation accepts the client's password and then converts it to a cryptographic key by passing the text of the password through a one-way hashing function.
The KDC gets its copy of client's long-term key from the respective record in its account database. When it receives a request from the Kerberos client on client's workstation, the KDC searches its database for client, pulls up the releveant account record, and takes the long-term key from a field in the record associated with he account record..
Using the TGT
1. client makes a request to the KDC.
2. KDC responds by returning a session ticket for itself (TGT, a TGT contains a copy of the session key that the service uses to communicate with the client.), and a copy of the session key that the client can use in communicating with the KDC. The TGT is encrypted in the KDC's long-term key. The client's copy of the session key is encrypted in the user's long-term key.
3. When the client receives the KDC's reply to its initial request, it uses its cached copy of the user's long-term key to decrypt its copy of the session key. It can then discard the long-term key derived from the user's password, for it is no longer needed. In all subsequent exchanges with the KDC, the client uses the session key. Like any other session key, this key is temporary, valid only until the TGT expires or the user logs off. For that reason, it is called a logon session key .
4. Before it attempts to connect to a service, the client first checks its credentials cache for a session ticket to that service.
5. If it does not have one, it checks the cache again for a TGT.
6. If it finds a TGT, the client fetches the corresponding logon session key from the cache, uses this key to prepare an authenticator, and sends both the authenticator and the TGT to the KDC, along with a request for a session ticket for the service. In other words, gaining admission to the KDC is no different from gaining admission to any other service in the domain — it requires a session key, an authenticator, and a ticket (in this case, a TGT).
7. From the KDC's point of view, TGTs allow it to shave a few nanoseconds off the turnaround time for ticket requests. The KDC looks up the user's long-term key only once, when it grants an initial TGT. For all other exchanges with this client, the KDC can decrypt the TGT with its own long-term key, extract the logon session key, and use that to validate the client's authenticator.
Reference for Key generation and key usage of a system: http://technet.microsoft.com/
Please note the information is not written by myself. This was shared by WSO2 Developer. I'm just sharing here for those who interested about knowing the basics.
No comments:
Post a Comment