Kerberos详细原理介绍

1.         Kerberos 介绍

 在本章中将介绍票证交换原理,密钥分发中心(简称KDC)和身份验证机制。

Kerberos的实现主要考虑了身份验证,而不是授权。通过KDC,  Kerberos 解决的主要问题就是这个问题,“是的,你可以信任我,而这个人就是他声称的那个人”。

Kerberos的常见描述是安全的,支持单点登录的,可信第三方相互认证服务。它不存储有关UIDGID或主目录路径的任何信息。Kerberos仅处理身份验证服务,不执行授权服务。

Kerberos作为一种协议,有许多为不同的目的而开发的实现:

  • MIT Kerberos 来自90年代初的Athena项目。由于出口对加密技术的限制,在瑞典开发了另一种Kerberos实现,即Heimdal

  • Heimdal Kerberos:是MIT Kerberos的类似的实现,但 Heimdal不受出口规则的限制。最初在瑞典开发,旨在与MIT Kerberos完全兼容。自2000年麻省理工学院的出口限制被取消以来,两种实施方式都在世界范围内得到了更加广泛的应用;

  • Active Directory:是MicrosoftActive Directory服务,包含一个类似的Kerberos实现和一些其他服务(LDAP),它与MITHeimdal不直接兼容;

  • TrustBroker:由CyberSafe开发的Kerberos协议的商业实现。支持各种操作系统(WindowsUnixLinux),并提供与MITMicrosoft AD的许多现有Kerberos实现的完全互操作性; 

  • Shishi Kerberos 5GNU实现; 

接下来的章节,我们结合MIT 实现,详细介绍Kerberos的功能。  

2.         Kerberos 票据交换服务 

Kerberos的通信基于票据, 票据是一种通过网络传输并存储在客户端的加密数据方案, 存储类型取决于客户端的操作系统和配置。 通常情况下,出于兼容性原因,票据存储在/ tmp目录中,每个操作系统都有特定的文件系统来保存票据数据。 

Kerberos网络的主要核心部分是密钥分发中心(KDC),它由三部分组成: 

  • 身份验证服务器 Authentication Server):响应客户端发出的身份验证请求。 包含AS_REQUESTAS_REPLY部分,客户端获得票证授予票证(Ticket Granting Ticket TGT

  • 票证授予服务器(Ticket Granting Server):向客户端发出票证授予服务(TGS)。 包含TGS_REQUESTTGS_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);

•客户端时间戳;

•请求的票据有效期(通常为810小时); 

KDC收到AS_REQUEST消息,检查客户端的Principal是否在数据库中匹配,以及客户端计算机与KDC之间的时间戳是否足够接近(通常间隔为35分钟)。

如果必须进行预认证(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 TicketAS_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 中保存。认证过程及机制请见下图所示:

1541666933283083.png

 1541664256633111.png

4.         票据授予服务机制 (Ticket Granting Service)

 

如果客户端已经通过了身份验证机制,并且具有票证授予票证(TGT),假设 用户正在请求访问网络上的特定服务,如Web服务器和文件共享等,那么用户需要票证授予服务(TGS)。

 

同样,该请求分为两个步骤,TGS_REQUESTTGS_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直接向所请求的服务验证自己。该服务可以访问其keytabKeytab是一个存储服务密钥的文件,此密钥将允许服务解密客户端发送的TGS,并获取识别用户和创建安全上下文所需的所有信息。与TGT过程一样,TGS中的时间戳保证了消息的时效性。

通常情况下,会话密钥用于在客户端和服务之间签名或加密消息,它为客户端和服务提供了一种保证交换消息完整性的方法,并且可以创建安全的上下文,使得截获改变消息变得非常困难。

和其他安全协议相比,Kerberos是对其他安全协议的补充,如TLS / SSLIPsec;主要区别在于它们是基于非对称加密(RSA),而Kerberos是基于对称加密(DESAES)构建的。

 

以下是TGS 交互过程图示如下:

image.png

5.   结论 

我们可以将Kerberos协议分为三个主要阶段: 

1.认证过程(Authentication Process),其中用户(和Host)获得票证授予票证(TGT)作为认证令牌;

2.服务请求过程(Service Request Process),用户获得票证授予服务(TGS)以访问服务;

3.服务访问 (Service Access),用户(和Host)使用TGS进行身份验证和访问特定服务

图示如下:

 

1541663326198061.png

Kerberos详细原理介绍

发表评论

电子邮件地址不会被公开。 必填项已用*标注

5 + 二 =