Kerberosプロトコル：
Kerberos認証プロトコルは、主にユーザのみ認証情報が複数のサービス、すなわちSSO（シングルサインオンへのアクセスを得るために、このチケット（チケット認可チケット）を用いて検証することができる入力する必要があることを特徴とするコンピュータネットワーク（認証）のために使用されます）。協定はかなりのセキュリティを持っているように、各クライアントとサービス間の共有キーの設立以来。条件
のは、Kerberosプロトコルの前提条件を見てみましょう：
以下に示すように、クライアントのKDC、KDCとサービス契約前の仕事は、彼らの共有鍵となっている、とプロトコルメッセージがファイアウォールを貫通することができないため、これらの条件は、Kerberosプロトコルは、多くの場合、組織の内で使用される制限されています、それはアプリケーションシナリオX.509 PKIは異なっています。
プロセス Kerberosプロトコルは、2つの部分に分割されます。
1.クライアントは、KDCがサービスを認可チケットからTGT（チケット認可チケット）を取得し、KDC自身のアイデンティティ情報を送信し、クライアントとKDC TGTの間にスタートキーがクライアントへの応答を暗号化する前に合意しています。
この時点で、唯一の本当の鍵は、TGTを取得するために暗号化されたTGTを復号化することとKDCの間でクライアントを活用することです。
（このプロセスは、クライアントのパスワードが認証危険ようにするために、KDCに直接送信され、回避します）
他のサービス識別のアイデンティティによってように以前にKDCに他のTGTを使用して得られた2クライアントは、チケットサービスを要求します。
次のようにKerberosプロトコルの第二の部分の焦点が記載されています。
1． Client将之前获得TGT和要请求的服务信息(服务名等)发送给KDC，KDC中的Ticket Granting Service将为Client和Service之间生成一个Session Key用于Service对Client的身份鉴别。然后KDC将这个Session Key和用户名，用户地址（IP），服务名，有效期, 时间戳一起包装成一个Ticket(这些信息最终用于Service对Client的身份鉴别)发送给Service， 不过Kerberos协议并没有直接将Ticket发送给Service，而是通过Client转发给Service.所以有了第二步。
2． 此时KDC将刚才的Ticket转发给Client。由于这个Ticket是要给Service的，不能让Client看到，所以KDC用协议开始前KDC与Service之间的密钥将Ticket加密后再发送给Client。同时为了让Client和Service之间共享那个秘密(KDC在第一步为它们创建的Session Key)， KDC用Client与它之间的密钥将Session Key加密随加密的Ticket一起返回给Client。
3． 为了完成Ticket的传递，Client将刚才收到的Ticket转发到Service. 由于Client不知道KDC与Service之间的密钥，所以它无法算改Ticket中的信息。同时Client将收到的Session Key解密出来，然后将自己的用户名，用户地址（IP）打包成Authenticator用Session Key加密也发送给Service。
4． Service 收到Ticket后利用它与KDC之间的密钥将Ticket中的信息解密出来，从而获得Session Key和用户名，用户地址（IP），服务名，有效期。然后再用Session Key将Authenticator解密从而获得用户名，用户地址（IP）将其与之前Ticket中解密出来的用户名，用户地址（IP）做比较从而验证Client的身份。
5． 如果Service有返回结果，将其返回给Client。
总结
概括起来说Kerberos协议主要做了两件事
1． Ticket的安全传递。
2． Session Key的安全发布。
再加上时间戳的使用就很大程度上的保证了用户鉴别的安全性。并且利用Session Key，在通过鉴别之后Client和Service之间传递的消息也可以获得Confidentiality(机密性), Integrity(完整性)的保证。不过由于没有使用非对称密钥自然也就无法具有抗否认性，这也限制了它的应用。不过相对而言它比X.509 PKI的身份鉴别方式实施起来要简单多了。