kerboros详解
协议概述
这个协议以希腊神话中的人物Kerberos(或者Cerberus)命名,他在希腊神话中是Hades的一条凶猛的三头保卫神犬。
Kerberos 是一种网络认证协议,其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证,无需基于主机地址的信任,不要求网络上所有主机的物理安全,并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下, Kerberos 作为一种可信任的第三方认证服务,是通过传统的密码技术(如:共享密钥)执行认证服务的。
原理介绍
认证过程具体如下:
客户机向认证服务器(AS)发送请求,要求得到某服务器的证书,然后 AS 的响应包含这些用客户端密钥加密的证书。
证书的构成为:
(1)服务器 “ticket” ;(2)一个临时加密密钥(又称为会话密钥 “session key”) 。
客户机将 ticket (包括用服务器密钥加密的客户机身份和一份会话密钥的拷贝)传送到服务器上。会话密钥可以(现已经由客户机和服务器共享)用来认证客户机或认证服务器,也可用来为通信双方以后的通讯提供加密服务,或通过交换独立子会话密钥为通信双方提供进一步的通信加密服务。
述认证交换过程需要只读方式访问 Kerberos 数据库。但有时,数据库中的记录必须进行修改,如添加新的规则或改变规则密钥时。修改过程通过客户机和第三方 Kerberos 服务器(Kerberos 管理器 KADM)间的协议完成。有关管理协议在此不作介绍。另外也有一种协议用于维护多份 Kerberos 数据库的拷贝,这可以认为是执行过程中的细节问题,并且会不断改变以适应各种不同数据库技术。
认证步骤详解:
(1) 客户端client将登录客户端的用户名、地址、时间戳信息发送给AS认证服务器,用来生成票据许可票据(TGT)+会话密钥(sessionKEY);
(2) AS服务器收到客户端client的请求后,KDC服务器生成随机会话密钥(session key)得到密钥K,使用客户端登录用户的NTLM hash对会话密钥(session key )进行加密得到密钥A,KDC服务器用户的NTLM hash对会话密钥(session key )客户端相关信息(client info)、时间戳(timestamp)等信息加密得到TGT,最后将会话密钥(key1)A和TGT一起发送给客户端;
(3) 客户端对收到的请求密钥A,使用客户端账户的NTML hash对A进行解密得到(session key)密钥K,解密后的密钥K对客户端相关信息(client info)、时间戳(timestamp)进行加密得到B,最后将密钥(key2)B与TGT发送给TGS;
(4) TGS 收到客户端的请求后,使用 KDC 的 NTLM Hash 解密 TGT,得到 Session Key和时间戳 (timestamp) 、客户端相关信息(Client Info),使用 TGT 解密出的 Session Key 解密密文B,得到时间戳 (timestamp) 和客户端相关信息(Client Info)。之后对比这俩解密通过后会随机生成一个新的会话密钥(session key),并用生成的新会话密钥对时间戳 (timestamp) 和客户端相关信息(Client Info)进行加密得到密文C,使用TGS服务器的NTML hash对新的会话密钥(session key)和(timestamp) 和客户端相关信息(Client Info)密文C进行加密得到最终票据(Ticket)即ST(Service Ticket),最后一起发送给client;
(5) 客户端client最后将服务票据ST(Service Ticket)和密文C直接请求服务。
(6) 服务票据ST(Service Ticket)和密文C解密后进行鉴别授权。
举个栗子:
小K和小J这俩小情侣(客户机)想去坐高铁旅行,得先需要买票吧,买票得经过售票员的身份认证吧(AS认证服务器),认证完成后售票员会给他俩火车票吧(票据和秘钥),到了检票口需要检票人员检票吧(TGS票据授权服务器),检票完成后会给他俩火车票吧(返回票据和秘钥),获得检票员的许可才可以通过吧,小情侣拿着火车票去旅行咯(SS服务器)。
相关名词:
AS(Authentication Server)= 认证服务器
KDC(Key Distribution Center)= 密钥分发中心
TGT(Ticket Granting Ticket)= 票据授权票据,票据的票据
ST(Service Ticket)= 服务授权票据
TGS(Ticket Granting Server)= 票据授权服务器
SS(Service Server)= 特定服务提供端
参考文献
https://adsecurity.org/?p=2011
https://www.cnblogs.com/stephen-init/p/3980503.html