【网络安全技术】实体认证技术Kerberos
一、什么是Kerberos
Kerberos解决的是客户端与服务器通信场景中，确保客户端服务器双方的身份可信，并提供对称密钥的分发来加密传输。是一个应用层的协议。
二、一个简单的模型
1.看这个基础的模型，客户端要和服务器通信，他先将自己的名称、密码和要访问的服务器的名称发给Authentication Server。AS里面存了可信用户的名称和密码。
2.AS验证没问题后，回给客户端一个票据，这个票据是用服务器和AS的对称密钥加密的（客户端名称，客户端ip地址，服务器名称）。
3.客户端收到后，把自己的名称和拿到的票据发给服务器，开始通信。
几个问题：
1.只认证了客户端，保护了服务器不会被非授权的用户访问，但没有保护客户端。
2.在第一条中，客户端的密钥明文传输。
三、进一步
1.这次不传口令，只传客户端id，服务器id。
2.基于“能正确解密的人就是合法用户”的思想，AS向客户端回一个用客户端密钥加密的ticket，如果客户端能正确解密出ticket，那就说明客户端是合法的，他就能接下来和服务器通信。
3.还是一样，把ticket和客户端id发给服务器，开始通信。
几个问题：
1.每访问一次服务器，就需要认证一次，客户端密钥被频繁使用，样本多了容易吃唯密文攻击。而且这个过程确实是多余的，认证一次就行了。这个可以将AS一分为二来解决。
2.票会被无限次使用，因为没有过期时间限制。
3.还存在单向认证问题，没有保护客户端。
四、再进一步
这次将AS一分为二，一个负责认证客户端，一个负责分发票据。
1.跟刚才类似，不过这次是要向tgs服务器要票，所以是IDtgs。
2.AS用客户端的对称密钥加密ticket tgs，这个用来向tgs服务器要票。这个ticket使用tgs服务器加密的（客户端id，客户端ip，tgs服务器id，时间戳1，寿命）。这样一分为二，解决了多次认证，重复使用密钥的问题。
3.客户端向tgs服务器要某一服务器的票，附上刚拿到的ticket tgs。
4.tgs服务器收到后会用自己和AS的对称密钥解密，然后取出里面的信息，这里面加了时间戳，避免了这个ticket tgs被无限次使用的问题。然后去自己的数据库里查服务器的信息，给客户端会服务器的票据。这个票据使用服务器的对称密钥加密，加密了（客户端id，客户端ip，服务器id，时间戳2，寿命），想想这些都有什么用，客户端id是为了指定只有这个客户端能用，ip是给服务器核对用的，服务器id不知道有什么用。这里加了时间戳解决了上一个方案的票据无限次使用问题。
5.客户端收到之后，把自己的id和这个票据发给服务器，开始通信。
几个问题：
1.第二张ticketv被别人捡到，就直接冒充这个客户端去用了，会被重放。
2.还是单向认证问题。
五、Kerberos V4
1.这次还给第一条加上了时间戳，这是为了什么？
2.AS用客户端的密钥加密（客户端和tgs之间的对称密钥，tgs id，时间戳2，寿命，ticket tgs）
ticket tgs是用tgs的密钥加密的（客户端和tgs之间的对称密钥，客户端id，客户端ip，tgs id，时间戳2，寿命）
3.客户端收到之后，解密，解出来ticket tgs，并使用他和tgs之间的对称密钥加密（客户端id，客户端ip，时间戳3）作为Authenticator，（这个是为了证明这条消息是认证的客户端发的，因为这条消息是明文传，所以ticket tgs会被别人拿去重放，有了authenticator，里面有用session key加密的时间戳，就能证明是客户端了，因为别人是没有这个session key的）；附上ticket tgs，要访问的服务器id，发给tgs。所以这个客户端和tgs之间的session key的作用，就是防止ticket tgs被别人拿走重放。哪如果别人直接把ticket tgs和authenticator一块拦截然后重放，不就成功了？其实是不会的，因为就算你拦截然后重放了，接下来tgs发给你的包也是用session key加密的，你解不开，就没有后续了。
4.tgs收到之后，先看ticket的时间戳过期没，然后从里面解出来他和客户端之间的对称密钥，再拿对称密钥解密authenticator，成功解密之后拿出时间戳，看时间对不对，因为这个authenticator也有可能被重放。这样下来，就成功验证客户端身份了。
然后他给客户端回信，用他和客户端之间的session key加密（客户端和服务器之间的session key，服务器id，时间戳4，ticket v）
ticket v是用服务器的对称密钥加密的（客户端服务器之间的session key，客户端id，客户端ip，服务器id，时间戳4，寿命）
5.客户端收到之后，用session key从里面接出来他和服务器的session key，还有用于登录服务器的票据。附上自己的Authenticator，发给服务器，这里需要authenticator的原因同理，是因为这里的ticket只能明文传，所以会被重放，需要认证。
6.服务器收到之后，跟刚才一样，先把ticket v拆开，拿出session key，然后对authenticator进行认证，确认是真的客户端，然后拆出authenticator里的时间戳5，加上1，然后再用session key加密回给客户端，这里是为了证明他是真的服务器，因为只有真的服务器能解开ticket v，取出客户端和服务器之间的session key，然后解开authenticator，取出时间戳5，并做运算，然后在加密还回去。
