内容
1. Kerberos 介绍
在本章中将介绍票证交换原理,密钥分发中心(简称KDC)和身份验证机制。
Kerberos的实现主要考虑了身份验证,而不是授权。通过KDC, Kerberos 解决的主要问题就是这个问题,“是的,你可以信任我,而这个人就是他声称的那个人”。
Kerberos的常见描述是安全的,支持单点登录的,可信第三方相互认证服务。它不存储有关UID,GID或主目录路径的任何信息。Kerberos仅处理身份验证服务,不执行授权服务。
Kerberos作为一种协议,有许多为不同的目的而开发的实现:
-
MIT Kerberos: 来自90年代初的Athena项目。由于出口对加密技术的限制,在瑞典开发了另一种Kerberos实现,即Heimdal;
-
Heimdal Kerberos:是MIT Kerberos的类似的实现,但 Heimdal不受出口规则的限制。最初在瑞典开发,旨在与MIT Kerberos完全兼容。自2000年麻省理工学院的出口限制被取消以来,两种实施方式都在世界范围内得到了更加广泛的应用;
-
Active Directory:是Microsoft的Active Directory服务,包含一个类似的Kerberos实现和一些其他服务(LDAP),它与MIT和Heimdal不直接兼容;
-
TrustBroker:由CyberSafe开发的Kerberos协议的商业实现。支持各种操作系统(Windows,Unix,Linux),并提供与MIT到Microsoft AD的许多现有Kerberos实现的完全互操作性;
-
Shishi: Kerberos 5的GNU实现;
接下来的章节,我们结合MIT 实现,详细介绍Kerberos的功能。
2. Kerberos 票据交换服务
Kerberos的通信基于票据, 票据是一种通过网络传输并存储在客户端的加密数据方案, 存储类型取决于客户端的操作系统和配置。 通常情况下,出于兼容性原因,票据存储在/ tmp目录中,每个操作系统都有特定的文件系统来保存票据数据。
Kerberos网络的主要核心部分是密钥分发中心(KDC),它由三部分组成:
-
身份验证服务器 (Authentication Server):响应客户端发出的身份验证请求。 包含AS_REQUEST和AS_REPLY部分,客户端获得票证授予票证(Ticket Granting Ticket) 即TGT;
-
票证授予服务器(Ticket Granting Server):向客户端发出票证授予服务(TGS)。 包含TGS_REQUEST和TGS_REPLY部分,客户端获取TGS,允许客户端对网络上可访问的服务进行身份验证;
-
KDC数据库: 存储所有KDC密钥(客户端和服务的密钥),以及与Kerberos帐户(创建日期,策略等)相关的一些信息;
通常情况下,KDC服务应该安装在网络上特定的服务器上,专用于提供Kerberos服务, 主要是出于安全目的:由于KDC存储包含所有密钥的数据库,如果KDC密钥数据库遭到泄漏,那么攻击者可以模拟存储在KDC数据库中的任何服务和客户端。
Kerberos帐户通过主体(Principal)命名,相当于Unix帐户的用户名。
接下来我们将专注于介绍Kerberos 5机制。
3. 身份验证机制 – 票证授予票证
身份验证机制是Kerberos认证机制中进行的第一步,它为用户提供票证授予票证(TGT),通过该票据,可以访问特定的在Kerberos KDC注册的服务,进行单点登录等。
第1步:验证服务请求-AS_REQUEST
以纯文本形式发送到KDC的第一条消息。AS_REQUEST包含:
?客户的主体名称 (Principal Name);
?票证授予服务器的主体(称为“krbtgt principal”,用于获得TGS);
?客户端时间戳;
?请求的票据有效期(通常为8至10小时);
KDC收到AS_REQUEST消息,检查客户端的Principal是否在数据库中匹配,以及客户端计算机与KDC之间的时间戳是否足够接近(通常间隔为3到5分钟)。
如果必须进行预认证(Pre-Authentication),KDC将不会立即返回TGT,它将发送NEEDED_PREAUTH消息,并要求客户端在返回TGT之前提供一些预认证数据。通常情况下,使用的方法是PA-ENC-TIMESTAMP,其中当前时间戳使用用户密钥加密,客户端即是用户的密码。
在这种情况下,客户端将重新发送AS_REQUEST消息,这次包含加密时间戳。如果预认证成功,KDC将返回TGT; 接下来就是AS_REPLY步骤。
第2步:验证服务响应-AS_REPLY
上述第一步认证通过时,认证服务器(AS)会生成随机会话密钥(random session key)(”short term” key), KDC为该随机会话密钥生成了两个副本:一个发送给客户端,添加到AS_REPLY消息中,第二个副本用于票证授予服务器(Ticket Granting Server),该会话密钥副本主要用于以后与其他有关的kerberized服务进行协商。
如果客户端成功进行了身份验证,KDC将返回包含Ticket Granting Ticket的AS_REPLY消息。它将存储在某种凭证缓存 (Credential Cache)中,以备将来使用。消息使用用户密钥加密,从而防止别的用户对其进行解码。
AS_REPLY消息由两层组成:第一层消息是由用户密钥加密的,第二层是TGT本身,首先使用Ticket Granting Server的密钥进行加密,然后使用用户密钥重新加密。这样,只有受信任的用户才能解密消息并获得TGT。
AS_REPLY消息的内容如下:
使用用户密钥进行加密的:
?用户的会话密钥副本
?票据的有效期
?krbtgt Principal 名称
使用Ticket Granting Server的密钥先加密,然后再使用用户密钥进行加密,该消息就是TGT:
?会话密钥的副本
?有效的票据有效期
?KDC时间戳
?客户端Principal (client principal)
?客户端IP地址
注意:虽然TGT已解密并缓存到客户端,但其内容却无法在客户端读取。 它使用Ticket Granting Server的密钥进行有效加密,该密钥仅在Ticket Granting Server 中保存。认证过程及机制请见下图所示:
4. 票据授予服务机制 (Ticket Granting Service)
如果客户端已经通过了身份验证机制,并且具有票证授予票证(TGT),假设 用户正在请求访问网络上的特定服务,如Web服务器和文件共享等,那么用户需要票证授予服务(TGS)。
同样,该请求分为两个步骤,TGS_REQUEST和TGS_REPLY。 出于安全原因,这两条消息都是加密的。
第1步:票证授予服务请求-TGS_REQUEST
当用户希望访问kerberized服务时,用户首先必须向服务验证用户本身。 该验证需要将TGS_REQUEST发送给票证授予服务器 (Ticket Granting Server)进行。TGS_REQUEST
消息由以下几个元素组成:
?TGS请求本身,包含服务主体(Service Principal)和请求的生命周期;
?身份验证阶段获得的TGT(成功认证后);
? 一个 Authenticator
Authenticator是使用在AS过程中获取的临时会话密钥加密的消息,包含用户主体(User Principal)和时间戳, 这样,KDC能够确保此消息来自可以信任的客户,即首先检查先前协商的临时会话密钥,然后通过时间戳来检查消息的时间有效性。
在确认有效的TGT和正确的身份验证后,票证授予服务器将返回TGS。
第2步:票证授予服务响应-TGS_REPLY
在该阶段,KDC服务器生成一组新的会话密钥。
票证授予服务响应消息通过AS阶段获取的会话密钥进行加密, 因此,只有在身份验证阶段向KDC有效识别自己的用户才可能读取其内容,并从中提取TGS。
TGS_REPLY消息包含:
使用通过AS阶段获取的会话密钥加密:
?为用户生成的新的会话密钥
?有效的票据有效期
?服务的主体名称 (Service Principal)
首先使用KDC服务的密钥加密,然后使用AS阶段的临时会话密钥加密。TGS包含的内容如下:
?用于服务的新会话密钥
?有效的票据有效期
?KDC时间戳
?用户主体 (Client Principal)
?客户端IP地址
第3步:访问KDC注册的服务
如果用户获得了TGS,可以用TGS直接向所请求的服务验证自己。该服务可以访问其keytab,Keytab是一个存储服务密钥的文件,此密钥将允许服务解密客户端发送的TGS,并获取识别用户和创建安全上下文所需的所有信息。与TGT过程一样,TGS中的时间戳保证了消息的时效性。
通常情况下,会话密钥用于在客户端和服务之间签名或加密消息,它为客户端和服务提供了一种保证交换消息完整性的方法,并且可以创建安全的上下文,使得截获改变消息变得非常困难。
和其他安全协议相比,Kerberos是对其他安全协议的补充,如TLS / SSL或IPsec;主要区别在于它们是基于非对称加密(RSA),而Kerberos是基于对称加密(DES和AES)构建的。
以下是TGS 交互过程图示如下:
5. 结论
我们可以将Kerberos协议分为三个主要阶段:
1.认证过程(Authentication Process),其中用户(和Host)获得票证授予票证(TGT)作为认证令牌;
2.服务请求过程(Service Request Process),用户获得票证授予服务(TGS)以访问服务;
3.服务访问 (Service Access),用户(和Host)使用TGS进行身份验证和访问特定服务;
图示如下: