Basic
为了减轻服务器的负担，我们需要设计一个专门的认证服务器AS，储存所有用户的口令，认证了用户身份之后再通知应用服务器引入ticket：客户把自己的ID（IDc)，要访问的服务器的ID (IDv) 和自己的口令 (Pc) 发给AS，AS查验用户和口令是否合法，是否有权访问V，都符合就给客户发一张ticket，客户凭借ticket和IDc去访问V
$ticket=E_{Kv}[IDc, ADc（用户网络地址）, IDv] $，ticket中包含的信息，谁的票，访问哪儿的票，这些信息用V与AS之间的共享密钥Kv加密，加密的同时也认证了AS（避免敌手假扮AS）
上述机制中还存在4个问题
Q1：访问多个服务器需要多次申请票据，多次输入口令会造成不安全
solution：
- 引入票据许可服务器（TGS，类似售票处），AS只认证，认证之后发放票据许可票据（类似允许你买票的身份证明）
(Ticket_{tgs})
，用来访问V的服务许可票据(TicketV)
由TGS来发。这样ID和password就只在认证时使用1次- 一类V之间可以共享Kv和票据
Q2：口令明文传送（C->AS）
solution： AS与C之间共享用户口令Pc->Kc，AS与TGS之间共享Ktgs，TGS和V之间共享Kv，不用再发送口令
Q3：票据重用
solution：引入时间戳（TS，消息发送时间）和有效期（LT）
PS：时间戳和序列号可以保证消息的新鲜性，但很容易被预测，可以使用挑战-响应协议，用随机数来防止重用，但复杂度比较高
Q4：票据冒领
solution：给谁的信息就用谁的密钥来加密，防止被冒领
但是TGS没有Kc，C也没有Kv，于是就由AS来帮TGS和C之间生成
(K_{c,tgs})
，TGS帮C和V生成(K_{c,v})
，同时，这两个密钥也要放到票据中，用来身份认证，防止敌手等到用户退出之后使用窃听到的票据备份进行重用AS为TGS和C生成了
(K_{c,tgs})
后，就连同(Ticket_{tgs})
一起发给C，TGS收到(Ticket_{tgs})
后，解密得到里面的(K_{c,tgs})
，然后回复C的消息就用(K_{c,tgs})
加密。现在我们解决了以上四个问题，来梳理一下，现在的票据长啥样？
票据包含双方的ID，为双方生成的共享密钥，TS，TL，给谁的票据就用谁的密钥加密
(Ticket_{tgs}=E_{Ktgs}{Kc,tgs, IDc, ADc, IDtgs, TS_2, LT_2})
更近一步的优化：C和V之间也要改成双向认证，C也要确认V的身份，TGS、V回复C的时候最外层就用会话密钥加密（信任第三方）
V回复C{
(TS_5)
+1} ，用(TS_5)
（用户发送消息的时戳）可以保证每次都不一样，类似TCP的序列号，+1可以记录交互了多少次最后我们就得到了Kerberos的整个流程：
