前面已介紹『鑰匙分配中心』（KDC）的基本觀念，接下來介紹幾種較常用的『KDC 認證協定』（KDC Authentication Protocol）。到目前為止，我們瞭解在一個 KDC 管轄範圍之內，使用者與 KDC 之間都擁有一把相同的『共享密鑰』，便利用此密鑰互相確定身份，然後KDC 再分配一把『會議鑰匙』（Session Key, KS）給使用者與伺服器（使用者要求服務的）雙方，它們完全利用此會議鑰匙來互相通訊。以下分別介紹 KDC 認證協定的幾種演算法。
回應者也許不存在，但發起者可能誤認是 KDC 鑰匙分配不當。
如果發起者重複要求的話，KDC 會連續送給回應者多把鑰匙，一旦回應者與發起者通訊時，可能會使用到舊的鑰匙。
容易遭受重播攻擊（Replay Attack）。攻擊者如欲破壞發起者與回應者之間的通訊，只要偽裝成發起者身份（利用 IP 位址），連續提出多個請求，回應者就擁有多把鑰匙了。
比較可行的實現方式，是由發起者攜帶會議鑰匙給回應者，如圖 14-1 (b) 所示。當 KDC 收到發起者請求之後，祇傳遞會議鑰匙給發起者（訊號 (2)），但其中包含一把通往回應者（如 Bob）的『門票』（Ticket），其格式如下：
然而，此門票是利用回應者的共享密鑰加密著，其中包含著發起者的身份識別與會議鑰匙，當然只有回應者可以解密得到其中訊息。發起者將此門票傳送給回應者之後，兩者便可以利用該會議鑰匙（KS）來通訊。由此可以看出，發起者與回應者之間一定採用相同的會議鑰匙通訊，而且回應者也不至於使用舊的鑰匙來通訊。
圖 14-1 (b) 認證協定還是有缺陷的地方，如果攻擊者可以攔截到門票（訊號 (3)），甚至不需要破解它，只要連續向回應者發出重複攻擊，也可以得到利用會議鑰匙（KS）加密的密文。如此一來，攻擊者只要稍加努力，便可得到許多明文與密文配對，欲找出會議鑰匙也不是困難的事；或是攻擊者偽裝成發起者身份，發送門票給回應者，回應者也很難辨別對方是冒充的。因此，並非只利用 KDC 來分配鑰匙就可以，通訊雙方還是需要確認所持有的鑰匙是否相同，如此一來，便牽涉到『相互認證』（Mutual Authentication）的問題。