一、什么是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,并做运算,然后在加密还回去。