用户认证

用户认证【Authentication】解决的是“如何证明某个人确确实实就是他或她所声称的那个人”的问题。

下面讲主要讲Kerberos，太复杂了……

基于对称加密的用户认证

双向认证

前提：通过KDC完成，KDC与A有密钥Ka，KDC与B有密钥Kb

A→KDC：IDA∥IDB∥N1

A向KDC发出会话密钥请求。请求的消息由两个数据项组成：一是A和B的身份IDA和IDB，二是本次业务的唯一标识符N1，每次请求所用的N1都应不同，常用一个时间戳、一个计数器或一个随机数作为这个标识符。

KDC→A：E(Ka[Ks∥IDA∥IDB∥N1∥E(Kb[Ks∥IDA])])。

KDC对A的请求发出应答。应答是由加密Ka加密的信息，因此只有A才能成功地对这一信息解密，并A相信信息的确是由KDC发出的。

KDC将使用Kb加密的ks数据发送给A【这里有个问题，为什么KDC不直接用Kb加密的Ks数据，直接发给B，而是由A发送给B?】

原因1：由于一个KDC会面对若干不同的A【很多个不同的客户端】, 而每个A都具有一个不同的密钥K。那么KDC就会为所有的A维护这样一个密钥K的列表，这样做对于KDC来说是比较麻烦而低效的。
原因2：由于网络传输的不确定性，可能出现这样一种情况：A很快获得密钥Ks，并将这个密钥Ks加密消息，并发送给B，但是用于B的密钥Ks确还没有收到，B无法解密消息，所以需要下面的第3步。

A→B：E(Kb[ Ks∥IDA])。

A收到KDC响应的信息后，同时将会话密钥Ks存储起来，同时A将经过【收KDC加密的，A只是转发】KDC与B的共享密钥加密过的信息传送给B。

B收到后，得到会话密钥Ks，并从IDA可知对方是A，而且还丛EKb知道Ks确实来自KDC。

Kerberos

先来举个例子：如果把 Kerberos 中的票据类比为一张火车票，那么 Client 端就是乘客，Server 端就是火车，而 KDC 就是就是车站的认证系统。如果Client端的票据是合法的（由你本人身份证购买并由你本人持有）同时有访问 Server 端服务的权限（车票对应车次正确）那么你才能上车。当然和火车票不一样的是 Kerberos 中有存在两张票，而火车票从头到尾只有一张。

在KDC中又分为两个部分：【AS】Authentication Service和【TGS】Ticket Granting Service

粗流程

当 Client 想要访问 Server 上的某个服务时，这个过程分为三步骤：

Client向AS申请【TGT】（Ticket Granting Ticket，票据授权票据？？？什么翻译……）
Client向TGS【拿着TGT】申请用于访问Server的Ticket【对应TGT的第一个T】
Client向Server对自己的认证向其提交Ticket

Kerberos大流程

好了，知道粗流程后可以去考试了，如果有兴趣，可以看下面的具体流程，我已经尽量结合资料更通俗地讲解了

大步骤一、Client向AS交互

步骤1、Client向As发送

Client向AS【KDC的第一个部分】发送Authentication Service Request【简写成KRB_AS_REQ】

为了确保KRB_AS_REQ仅限于Client和KDC知道，Client使用自己的对称加密Master Key对KRB_AS_REQ的主体部分进行加密
KDC可以通过账户数据库获得该Client的Master Key。【也就是说Master Key只有KDC和Client知道】

KRB_AS_REQ的大体包含以下的内容：

Pre-authentication data：包含用以证明Client身份的信息。说白了，就是证明自己知道自己声称的那个account的Password。一般地，它的内容是一个被Client的Master key加密过的Timestamp。
Client name & realm: 简单地说就是Domain name\Client
Server Name：注意这里的Server Name并不是Client真正要访问的Server的名称，而我们也说了TGT是和Server无关的（Client只能使用Ticket，而不是TGT去访问Server）。这里的Server Name实际上是KDC的Ticket Granting Service的Server Name。

步骤2、As向Client回复

AS通过它接收到的KRB_AS_REQ验证发送方的是否是在Client name & realm中声称的那个人，也就是说要验证发送放是否知道Client的Password。

所以AS只需从账户数据库中提取Client对应的Master Key对Pre-authentication data进行解密，如果是一个合法的Timestamp，则可以证明发送放提供的是正确无误的密码。【解不出来，说明数据库里面没这个人；或着Client加密用的Master Key有问题】

验证通过之后，AS将一份Authentication Service Response【简称KRB_AS_REP】发送给Client。

KRB_AS_REQ主要包含两个部分：

第一部分：用Client的Master Key加密过的Logon Session Key【Logon Session Key用来让Client与TGS通信时加密用，只有Client和TGS知道】
第二部分：被KDC加密的TGT
- 这个TGT是关键数据，并且TGT只能由KDC自己解密，可以是TGS解密，任何其它人都无法解密出来
- TGT里面包含了另一个密钥，下面会提到，这个密钥是Logon Session Key

TGT包含以下的内容：

Session Key: SKDC-Client：Logon Session Key【让TGS解密出Client发来的Authenticator】
Client name & realm: 简单地说就是Domain name\Client
End time: TGT到期的时间。

步骤3、Client收到AS的回复

Client通过Client的Master Key对第一部分解密获得Logon Session Key【它用来让Client和TGS通信的密钥，只有Client和TGS知道】

Client携带着TGT和Session Key便可以进入下一步：Client与TGS【Ticket Granting Service】交互。

至此，Client向AS交互结束，Client得到了TGT【关键道具】和Logon Session Key【关键道具】

大步骤二、Client向TGS交互

步骤1、Client向TGS申请

Client向TGS【KDC中的第二部分】发送Ticket Granting Service Request【简称KRB_TGS_REQ】

KRB_TGS_REQ大体包含以下的内容：

TGT： Client从AS获得的TGT【用来向TGS证明，Client已经被AS认证了】，TGT被KDC的密钥进行加密【只能由KDC自己解开】
Authenticator：用来Client向TGS证明：这张TGT的拥有者就是Client自己
- 所以Client必须用TGS和自己的Logon Session Key来将一些认证信息加密。信息内容其实不重要，重要的是让TGS知道，用了理伦上只有TGS和Client知道的密钥“Logon Session Key”加密的信息
Client name & realm: 简单地说就是Domain name\Client。
Server name & realm: 简单地说就是Domain name\Server，这回是Client试图访问的那个Server。

步骤2、TGS向Client回复

TGS收到KRB_TGS_REQ后，在在发给Client真正的Ticket之前，先判断Client提供的那个TGT是否是AS颁发给Client的。

于是TGS需要通过Client提供的Authenticator来证明TGT是否AS发的，是否真的是发给Client的【上面也讲过】

但Authentication是通过Logon Session Key【上面提到过】进行加密的，而TGS并没有保存这个Logon Session Key。

所以TGS先得通过TGS的Master Key对Client提供的TGT进行解密，从而获得这个Logon Session Key，再通过这个Logon Session Key解密Authenticator进行验证。

身份验证通过后，TGS向Client发送Ticket Granting Service Response【KRB_TGS_REP】。

KRB_TGS_REP有两部分组成：

使用Logon Session Key加密过用于Client和Server的Session Key【Session Key是用来让Client与Server通信时加密用的密钥，只有Client和Server知道】
使用Server的Master Key进行加密的真正的Ticket。【注意这里是TSG用Server的Master Key】

真正的Ticket包含以下一些内容：