In-Depth

Smart Card Logon Integration with Kerberos

Learn the basic behind-the-scenes steps for Smart Card logon under Kerberos.

• By Roberta Bragg
• 10/01/2000

When smart cards are used for authentication in Win2K, a copy of the certificate and the private key can be stored on the smart card. When the user inserts the card in the reader, he or she will be prompted to enter the pin. What happens next? How does this operation provide the credentials necessary for a logon system based on Kerberos?

Kerberos doesn’t use public key cryptography; instead, it uses a session or symmetric key. In order for a smart card interface to work, some work has to occur before Kerberos can do its job. Win2K implements a proposed extension to the Kerberos standard and integrates smart card logon with Kerberos. Here’s what happens:

1. If a reader is attached to the user’s machine, the user is prompted to put in a card.
2. Then the user is prompted to enter a pin.
3. The logon request is passed to the Local Security Authority (LSA).
4. LSA communicates with the Kerberos authentication package on the client.
5. Kerberos sends a request to the Kerberos Distribution Center (KDC) on the domain controller for authentication. The request includes a copy of the x.509 certificate (from the smart card) in the pre-authentication data field of the request and is signed by the private key.
6. The KDC builds a certification path from the certificate to a root CA in the system root store.
7. In Win2K, there must be an enterprise Certification Authority (CA, published in Active Directory). This prevents a rogue CA certified in another CA hierarchy from issuing a certificate in the domain.
8. The KDC uses the public key from the certificate to verify the signature.
9. KDC verifies the timestamp is within skew time, the time period during which a request can be processed. This helps to detect a replay attack.
10. KDC looks in the AD for account information.
11. If all tests are passed, the KDC returns a Ticket Granting Ticket (TGT). The KDC provides a copy of its certificate as well and signs the returned information with its private key.
12. The client verifies the KDC by building a certificate path from the certificate to the trusted root CA and uses the KDC public key to verify the reply signature.
13. If all is OK, the normal Kerberos path is followed from here (the TGT is used to get a service ticket and hence to the user’s desktop).