【网络安全】Kerberos认证浅析

作者：漫天星雨2000 | 来源：互联网 | 2023-10-13 12:22

1引言在希腊神话中Kerberos是守护地狱之门的一条凶猛的三头神犬，而我们在本文中所要介绍的Kerberos认证协议是由美国麻省理工学院(MIT)首先提出并实现的&

1 引言
在希腊神话中Kerberos是守护地狱之门的一条凶猛的三头神犬&＃xff0c;而我们在本文中所要介绍的Kerberos认证协议是由美国麻省理工学院(MIT)首先提出并实现的&＃xff0c;是该校雅典娜计划的一部分。这个定名是贴切的&＃xff0c;因为Kerberos认证是一个三路处理过程&＃xff0c;依赖称为密钥分发中心&＃xff08;KDC&＃xff09;的第三方服务来验证计算机相互的身份&＃xff0c;并建立密钥以保证计算机间安全连接。本质上每台计算机分享KDC一个秘钥&＃xff0c;而KDC有两个部件&＃xff1a;一个Kerberos 认证服务器和一个票据授权服务器。如果KDC不知道被请求目标服务器&＃xff0c;则会求助于另一个KDC来完成认证。它允许在网络上通讯的实体互相证明彼此的身份&＃xff0c;并且能够阻止窃听和重放等攻击手段。不仅如此&＃xff0c;它还能够提供对通讯数据保密性和完整性的保护。
Kerberos从提出到今天&＃xff0c;共经历了五个版本的发展。其中第一版到第三版主要由该校内部使用。当发展到第四版的时候&＃xff0c;已经取得了在MIT校外的广泛认同和应用。由于第四版的传播&＃xff0c;人们逐渐发现了它的一些局限性和缺点&＃xff0c;例如适用网络环境有限、加密过程存在冗余等等。MIT充分吸取了这些意见&＃xff0c;对第四版进行了修改和扩充&＃xff0c;形成了今天非常完善的第五版。第五版由John Kohl和Clifford Neuman设计&＃xff0c;在1993年作为RFC 1510颁布&＃xff0c;在2005年由RFC 4120取代&＃xff0c;目的在于克服第四版的局限性和安全问题&＃xff0c;用更细化和明确的解释说明了协议的一些细节和使用方法。

2 Kerberos认证应用环境假定
Kerberos协议的基本应用是在一个分布式的Client/Server 体系结构中&＃xff0c;采用一个或多个Kerberos 服务器提供鉴别服务。当客户端想请求应用服务器上的资源时&＃xff0c;首先由客户端向密钥分发中心请求一张身份证明&＃xff0c;然后将身份证明交给应用服务器进行验证&＃xff0c;在通过服务器的验证后&＃xff0c;服务器就会为客户端分配所请求的资源。
图1 Kerberos的基本应用
Kerberos协议本身并不能完全解决网络安全性问题&＃xff0c;它是建立在一些假定之上的&＃xff0c;只有在满足这些假定的环境中它才能正常运行。
&＃xff08;1&＃xff09;不能对拒绝服务(Denial of Service)攻击进行防护。Kerberos不能解决拒绝服务攻击&＃xff0c;在该协议的很多环节中&＃xff0c;攻击者都可以阻断正常的认证步骤。这类攻击只能由管理员和用户来检测和解决。
&＃xff08;2&＃xff09;主体必须保证他们的私钥的安全。如果一个入侵者通过某种方法窃取了主体的私钥&＃xff0c;他就能冒充身份。
&＃xff08;3&＃xff09;Kerberos无法应付口令猜测攻击。如果一个用户选择了弱口令&＃xff0c;那么攻击者就有可能成功地用口令字典破解掉&＃xff0c;继而获得那些由源自于用户口令加密的所有消息。
&＃xff08;4&＃xff09;网络上每个主机的时钟必须是松散同步的。这种同步可以减少应用服务器进行重放攻击检测时所记录的数据。松散程度可以以一个服务器为准进行配置。时钟同步协议必须保证自身的安全&＃xff0c;才能保证时钟在网上同步。
&＃xff08;5&＃xff09;主体的标识不能频繁地循环使用。由于访问控制的典型模式是使用访问控制列表(ACLs)来对主体进行授权。如果一个旧的ACL还保存着已被删除主体的入口&＃xff0c;那么攻击者可以重新使用这些被删除的用户标识&＃xff0c;就会获得旧ACL中所说明的访问权限。

3 Kerberos认证的工作过程

3.1 Kerberos认证的基本原理

在网络中&＃xff0c;认证主要用来解决各个通讯实体之间相互证明彼此身份的问题。对于如何进行认证&＃xff0c;我们通常会采用这样的方法&＃xff1a;如果一个秘密仅仅有认证方和被认证方知道&＃xff0c;认证方可以通过让被认证方提供这个秘密来证明对方的身份。这个过程实际上涉及到认证的三个重要方面&＃xff1a;秘密如何表示、被认证方如何向认证方提供秘密、认证方如何识别秘密。

基于这三个方面&＃xff0c;Kerberos认证可以进行最大限度的简化成Client和Server两个通讯实体&＃xff0c;他们之间共同的秘密用KServer-Client来表示。Client在认证过程中向Server提供以明文形式表示的Client标识和使用KServer-Client加密的Client标识以便于让Server进行有效的认证&＃xff1a;

由于这个秘密仅仅被Client和Server知晓&＃xff0c;所以被 Client加密过的Client标识只能被Client和Server解密。Server接收到Client传送的这两组信息&＃xff0c;先通过KServer-Client对后者进行解密&＃xff0c;随后将解密的数据同前者进行比较&＃xff0c;如果完全一样&＃xff0c;则可以证明Client能够提供正确的KServer-Client&＃xff0c;而这个世界上&＃xff0c;只有真正的Client和自己知道KServer-Client&＃xff0c;这样就可以证明对方的真实性。

图2 客户端认证的简单过程

整个过程看起来非常简单&＃xff0c;但是实际上Kerberos认证远比这个过程复杂的多&＃xff0c;在了解Kerberos真实的认证过程之前我们先给出两个重要的概念&＃xff1a;

长期密钥&＃xff1a;在安全领域中&＃xff0c;有的密钥可能长期内保持不变&＃xff0c;比如密码&＃xff0c;可能几年都不曾改变。这样的密钥以及由此派生的其他密钥被称为长期密钥。长期密钥有这样的原则&＃xff1a;被长期密钥加密的数据不应该在网络上传输。因为任何加密算法都不可能做到绝对保密&＃xff0c;一旦这些被长期密钥加密的数据包被黑客截获&＃xff0c;在理论上&＃xff0c;只要有充足的时间&＃xff0c;都是可以通过计算获得用户用于加密的密钥的。

对于一个账户来说&＃xff0c;密码仅限于该账户的所有者知晓&＃xff0c;甚至对于管理员都应该是保密的。但是密码却又是证明身份的凭据&＃xff0c;所以必须通过基于密码的派生信息来证明用户的真实身份&＃xff0c;在这种情况下&＃xff0c;一般将账户密码进行Hash运算得到一个Hash值&＃xff0c;也可以称之为主密钥。由于Hash算法是不可逆的&＃xff0c;同时可以保证密码和主密钥派生的确定性&＃xff0c;这样既保证了密码的保密性&＃xff0c;同时又保证主密钥和密码本身在证明用户身份时具有相同的效力。

短期密钥&＃xff1a;由于被长期密钥加密的数据包不能在网络上传送&＃xff0c;所以需要使用另一种密钥来加密需要进行网络传输的数据。这种密钥只在一段时间内有效&＃xff0c;即使加密过的数据包被黑客截获&＃xff0c;等他把密钥计算出来的时候&＃xff0c;这个密钥早就已经过期了。我们把这种密钥称为短期密钥。

3.2 密钥分发中心——SServer-Client的分发

通过让被认证方提供一个仅限于他和认证方知晓的密钥来鉴定对方的真实身份。而被这个密钥加密的数据包需要在Client和Server之间传送&＃xff0c;所以这个密钥只可能是一个短期密钥&＃xff0c;它仅仅在Client和Server的一个Session中有效&＃xff0c;所以我们称这个密钥为Client和Server之间的会话密钥&＃xff0c;暂时表示为SServer-Client。

在介绍Client和Server是如何得到会话密钥之前要引入一个重要的角色&＃xff1a;Key Distribution Center&＃xff08;KDC&＃xff09;&＃xff0c;也就是密钥分发中心。KDC在整个Kerberos认证系统中作为Client和Server共同信任的第三方起着至关重要的作用。

图3 KDC分发会话密钥的简单过程

KDC分发SServer-Client的简单过程如上图所示&＃xff1a;首先 Client向KDC发送一个对SServer-Client的申请&＃xff0c;其中包括自己的信息以及希望访问的Server的信息。KDC在接收到这个请求的时候&＃xff0c;生成一个会话密钥&＃xff0c;为了保证这个密钥仅限于发送请求的Client和他希望访问的Server知晓&＃xff0c;KDC会为这个密钥生成两个拷贝&＃xff0c;分别被Client和Server使用。然后从数据库中提取Client和Server的主密钥分别对这两个拷贝进行对称加密。对于后者&＃xff0c;和会话密钥一起被加密的还有一些Client的信息。

KDC有了两个分别被Client和Server 的主密钥加密过的会话密钥&＃xff0c;KDC会将这两个被加密的拷贝一并发给Client&＃xff0c;属于Server的那一份将会由Client发送给Server。这样做可以轻松地解决两个问题&＃xff1a;首先Server不用维护一张庞大的会话密钥列表来应付不同的Client的访问&＃xff0c;降低了Server的负荷&＃xff1b;其次避免出现因为网络延时&＃xff0c;Client的认证请求比Server的会话密钥早到达Server端&＃xff0c;进而导致认证失败的情况。

3.3 鉴别码是有效证明自己的证据

在上述的过程之后Client实际上获得了两组信息&＃xff1a;一个是通过自己的主密钥加密的会话密钥&＃xff0c;另一个则是被Server的主密钥加密的数据包&＃xff0c;其中包含会话密钥和关于自己的一些确认信息。虽然通过一个双方知晓的密钥就可以对对方进行有效的认证&＃xff0c;但是在一个不安全的网络环境中&＃xff0c;这种简单的做法是存在安全漏洞的&＃xff0c;假设Client向Server发送的数据包被黑客截获&＃xff0c;该黑客随后将数据包作为自己的凭证冒充该Client对Server进行访问&＃xff0c;在这种情况下&＃xff0c;依然可以很顺利地获得Server的成功认证。为此&＃xff0c;Client需要提供更多的证明信息&＃xff0c;称为鉴别码。在Kerberos中这个鉴别码实际上就是关于Client的一些信息和当前时间的一个时间戳。

Client使用自己的主密钥对KDC加密的会话密钥进行解密从而获得SServer-Client&＃xff0c;随后创建鉴别码并用SServer-Client对其加密。最后连同从KDC获得的、被Server的主密钥加密过的数据包一并发送到Server端。我们把通过Server的主密钥加密过的数据包称为会话票据。

当Server接收到这两组数据后&＃xff0c;先使用他自己的主密钥对会话票据进行解密&＃xff0c;从而获得SServer-Client。随后使用SServer-Client解密鉴别码获取时间戳&＃xff0c;同当前的时间进行比较&＃xff0c;如果偏差超出一个可以接受范围&＃xff0c;Server会直接拒绝该Client的请求。Server会维护一个列表&＃xff0c;记录在可接受的时间范围内所有进行认证的Client和认证时间。对于时间偏差在可接受的范围中的Client&＃xff0c;Server会从列表中获得该Client最近一次认证时间&＃xff0c;只有当Client提供的时间戳晚于这个时间&＃xff0c;Server才会比较鉴别码中的客户端信息和会话票据中的客户端信息从而实现对Client的认证。这也就是为什么我们从一开始就需要假定网络中每台主机的时钟必须是松散同步的了。

图4 Kerberos双向验证过程

Kerberos一个重要的优势在于它能够提供双向认证&＃xff1a;不但Server可以对Client进行认证&＃xff0c;Client也能对Server进行认证。如果Client需要对他访问的Server进行认证&＃xff0c;会在他向Server发送的认证请求中设置一个是否需要双向认证的标志位。Server在对Client认证成功之后&＃xff0c;会把鉴别码中的时间戳提取出来&＃xff0c;通过SServer-Client进行加密&＃xff0c;当Client使用SServer-Client对Server回应的报文进行解密之后&＃xff0c;如果确认时间戳和原来的完全一致&＃xff0c;那么他可以认定这台Server正是他希望访问的Server。

3.4 票据授权服务——TGS

Kerberos实际上是一个基于票据的认证方式。 Client想要获取Server端的资源&＃xff0c;先得通过Server的认证&＃xff1b;而认证的先决条件是Client向Server提供从KDC获得的一个由 Server的主密钥加密过的会话票据。所以对Client来说&＃xff0c;获得会话票据是整个认证过程中最为关键的部分。

在 Kerberos中票据的分发过程远没有上面所讲的那么简单&＃xff0c;Client在从KDC处获得会话票据之前&＃xff0c;需要先获得一个授权&＃xff0c;被称为Ticket Granting Ticket&＃xff08;票据授权票据&＃xff0c;简称TGT&＃xff09;&＃xff0c;TGT的分发仍然是KDC来完成的。

首先Client向KDC发起对TGT的申请&＃xff0c;KDC在收到该申请后&＃xff0c;生成一个用于该Client与KDC进行安全通信的会话密钥&＃xff0c;暂时用SKDC-Client来表示。为了保证该会话密钥仅供该Client和自己使用&＃xff0c;KDC使用Client的主密钥和自己的主密钥对生成的会话密钥进行加密&＃xff0c;从而获得两个加密的SKDC-Client的拷贝。对于后者&＃xff0c;随会话密钥一起被加密的还包含以后用于鉴定Client身份的关于Client的一些信息&＃xff0c;这就是前面所说的TGT。最后KDC将这两份拷贝一并发送给Client。

图5 TGT申请过程

当Client收到KDC的两个加密数据包之后&＃xff0c;先使用自己的主密钥对第一个拷贝进行解密&＃xff0c;从而获得SKDC-Client&＃xff0c;并把它和TGT进行缓存。有了SKDC-Client和TGT&＃xff0c;Client自己的主密钥将不再需要&＃xff0c;因为此后Client可以使用SKDC-Client向KDC申请用以访问各个Server的票据&＃xff0c;SKDC-Client是一个短期密钥&＃xff0c;安全得到更好的保障&＃xff0c;也正是因为如此&＃xff0c;SKDC-Client具有自己的生命周期&＃xff0c;同时TGT和SKDC-Client相互关联&＃xff0c;当SKDC-Client过期&＃xff0c;TGT也就宣告失效&＃xff0c;此后Client不得不重新向KDC申请新的TGT&＃xff0c;KDC将会生成一个不同会话密钥和与之关联的TGT&＃xff0c;另外Client的注销操作也会导致SKDC-Client失效。

Client在获得SKDC-Client之后&＃xff0c;生成自己的鉴别码以及所要访问的Server名称&＃xff0c;并使用SKDC-Client进行加密。随后连同TGT一并发送给KDC。KDC使用自己的主密钥对TGT进行解密&＃xff0c;提取客户端信息和SKDC-Client&＃xff0c;然后使用SKDC-Client解密鉴别码&＃xff0c;获得鉴别码中的客户端信息&＃xff0c;对两个信息进行比较进而验证对方的真实身份。验证成功&＃xff0c;生成一份基于Client所要访问的Server的票据给Client&＃xff0c;之后的过程就像上面所讲述的一样进行了。

图6 会话票据分发过程

通过以上的介绍&＃xff0c;Kerberos认证的过程已经基本介绍清楚了&＃xff0c;首先Client向KDC申请TGT&＃xff0c;之后Client通过获得TGT向KDC申请用于访问Server的票据&＃xff0c;最后Client向Server提交票据用于认证。

4 Kerberos的子协议
上一节所讲述的Kerberos认证过程的三步是通过三个子协议来完成&＃xff0c;它们分别是&＃xff1a;Authentication Service Exchange、Ticket GrantingService Exchange和Client/Server Exchange。这三个子协议分别完成了Client向KDC申请TGT、Client通过获得的TGT向KDC申请用于访问Server的票据和Client向Server提交票据进行认证的三个过程。
图7 Kerberos三步认证过程

4.1 Authentication Service Exchange

首先Client向KDC的认证服务发送Authentication Service Request&＃xff08;KRB_AS_REQ&＃xff09;&＃xff0c;大体内容包含&＃xff1a;客户端名称、票据授权服务器名称以及一个被Client的主密钥加密的时间戳&＃xff0c;我们可以把它看作是票据的有效期。

认证服务从数据库中提取KRB_AS_REQ中携带的客户端名称所对应的主密钥对被加密的时间戳进行解密&＃xff0c;如果这个时间戳合法&＃xff0c;则可以证明发送方提供的是正确的密码&＃xff0c; 认证服务将一份包含使用Client的主密钥加密的会话密钥和被自己的主密钥加密的TGT的回应&＃xff08;KRB_AS_REP&＃xff09;发送给Client。这个TGT中包含了SKDC-Client、客户端名称和TGT到期的时间。

Client对第一部分解密获得SKDC-Client之后&＃xff0c;携带着TGT便可以进入下一步——TGS&＃xff08;Ticket Granting Service&＃xff09;Exchange。

4.2 Ticket GrantingService Exchange

Client向KDC的票据授权服务发送Ticket Granting Service Request&＃xff08;KRB_TGS_REQ&＃xff09;&＃xff0c;内容包括Client通过AS Exchange获得的TGT、使用SKDC-Client加密的客户端信息以及所需要访问的服务器名称。

票据授权服务收到请求后&＃xff0c;先得确认Client提供的那个TGT是否是AS颁发给它的。方法很简单&＃xff0c;KDC先使用自己的主密钥对Client提供的TGT进行解密&＃xff0c;获得SKDC-Client&＃xff0c;再使用SKDC-Client解密鉴别码进行验证。验证通过向对方发送Ticket Granting Service Response&＃xff08;KRB_TGS_REP&＃xff09;。回应报文也由两部分组成&＃xff1a;使用SKDC-Client加密的Client和Server的会话密钥&＃xff08;SServer-Client&＃xff09;和使用Server的主密钥加密的票据&＃xff0c;包含SServer-Client&＃xff0c;客户端名称和票据的到期时间。

Client收到回应报文后&＃xff0c;使用SKDC-Client解密第一部分&＃xff0c;获得SServer-Client。有了SServer-Client和票据&＃xff0c;Client就可以直接和Server进行交互&＃xff0c;而无需再通过KDC了。

4.3 Client/Server Exchange

最后Client使用票据和Server进行交互就由CS&＃xff08;Client/Server&＃xff09;Exchange来完成。Client通过TGS Exchange获得SServer-Client&＃xff0c;随后创建用于证明自己就是票据真正所有者的鉴别码&＃xff0c;并使用SServer-Client进行加密。最后将这个被加密过的鉴别码和票据作为应用服务请求&＃xff08;KRB_AP_REQ&＃xff09;发送给Server&＃xff0c;另外在请求中还包含一个标志位用于表示Client是否需要进行双向验证。

Server接收到请求之后&＃xff0c;通过自己的主密钥解密票据&＃xff0c;从而获得SServer-Client。接着使用SServer-Client解密鉴别码&＃xff0c;进而验证Client的身份。如果验证通过&＃xff0c;则让Client访问需要访问的资源&＃xff0c;否则直接拒绝对方的请求。

如果Client需要进行双向验证&＃xff0c;Server从鉴别码中提取时间戳&＃xff0c;使用SServer-Client进行加密&＃xff0c;并将其发送给Client用于Client验证Server的身份。

通过对上述三个子协议的介绍&＃xff0c;我们已经了解了整个Kerberos的认证过程。但是细心的读者也许会发现&＃xff0c;基于这三个子协议的Kerberos系统是存在一定的安全隐患的。在CS Exchange阶段&＃xff0c;Client携带的票据是被Server的主密钥加密的&＃xff0c;这显现不符合前面提出长期密钥的使用原则&＃xff0c;降低了Server的安全系数。

最直接的解决方式就是采用一个会话密钥&＃xff0c;而不是Server的主密钥对票据进行加密。这就是Kerberos的第四个子协议&＃xff1a;User-to-User Authentication Exchanges。票据是由KDC生成之后通过Client发送给Server的&＃xff0c;所以用于加密票据的自然是KDC和Server之间的会话密钥&＃xff08;SKDC-Server&＃xff09;。但是KDC是不会维护任何会话密钥的&＃xff0c;所以SKDC-Server只能靠申请票据的Client提供。

图8 Kerberos四步认证过程

上图描述了包含User-to-User Authentication Exchanges的认证过程&＃xff0c;这个过程由四步组成。较之前基于传统的认证过程多了第二步。

首先通过AS Exchange&＃xff0c;Client获得了属于自己的TGT&＃xff0c;便可凭此向KDC申请用于访问某个Server的票据。

第二步的主要任务是获得封装了SKDC-Server的属于Server的TGT。如果该TGT存在于Server的缓存中&＃xff0c;则Server会直接将其返回给Client。否则Server将通过AS Exchange从KDC获取。

接着Client通过向KDC提供自己的TGT&＃xff0c;Server的TGT以及鉴别码来申请用于访问Server的票据。KDC先用自己的主密钥解密Client的TGT获得SKDC-Client&＃xff0c;通过SKDC-Client解密鉴别码验证发送者的身份&＃xff0c;验证通过后再用自己的主密钥解密Server的TGT获得SKDC-Server&＃xff0c;并用SKDC-Server加密票据返回给Client。

最后&＃xff0c;Client将使用SKDC-Server加密的票据和SServer-Client加密的鉴别码访问Server&＃xff0c;Server通过SKDC-Server解密票据获得SServer-Client&＃xff0c;通过SServer-Client解密鉴别码实现对Client的验证。