Kerberos v4验证的实现过程

最新推荐文章于 2023-06-23 16:05:47 发布

Cynthea

最新推荐文章于 2023-06-23 16:05:47 发布

阅读量3.4k

点赞数 2

分类专栏：网络中的技术文章标签： authentication session exchange server service 加密

网络中的技术专栏收录该内容

7 篇文章 0 订阅

订阅专栏

Kerberos验证的名字来自于古希腊神话中的守护地狱之王Hades的三头犬的名字，其实现过程恰恰用到了三台服务器进行，即验证服务器（AS）、票据凭证服务器（TGS）和数据服务器（下文以Bob代称）。

当某个用户如Alice想通过Kerberos验证与数据服务器Bob通讯时需要经过6个步骤，详细如下：

Step 1、Alice->AS

Alice向AS发送自己的身份，如用户名：Alice。

Step 2、AS->ALice

AS用Alice在服务器上注册时所用的对称密钥（如Alice的登陆密码）加密将用于之后的验证过程的会话密钥Ks（Session Key）和已被TGS的密钥加密过的TGT（包括Alice的身份和Ks）。

Step 3、Alice->TGS

Alice在其客户机上输入密码即Ka解密出AS发送过来的Ks和TGT，之后用Ks加密一个时间戳以防第四方的重放攻击，最后将Ks（TGT）、数据服务器Bob的身份和TGT一并作为票据请求发送给TGS。

Step 4、TGS->Alice

TGS在收到Alice的票据请求后回送一个票据包括：用Ks加密过的Bob的身份和Alice和Bob之间的通讯密钥Kab、一个由Bob的密钥（即Kb）加密过的Alice的身份（可以包括Alice的IP、用户名等）、还有Kab共三样东西。

Step 5、Alice->Bob

Alice在受到TGS的票据后用Ks解出Kab后用Kab加密一个时间戳，之后将加密过的时间戳与TGS发送过来的鉴别码一起发送给Bob

Step 6、Bob->Alice

Bob分别用Kb、Kab解开Alice发送的鉴别码和时间戳后对Alice的IP、用户名及数据包的接收时间等进行验证，通过后用Kab加密另外一个时间戳回送给Alice。之后双方用Kab加密信息进行通讯。

缩写解释：

AS：Authentication Server 验证服务器

TGS：Ticket-Granting Server 票据验证服务器

TGT：Ticket-Granting Ticket 票据验证凭证

以上是Kerberos第四版协议的实现过程，在第五版中1、3、5步与v4一致，仅是在2、4中删除了票据的双重加密。

应该说Kerberos验证还是比较完善的但是专家们还是找到了几个潜在的问题，针对于v4但是对于v5也很多评价也适用。

第一是鉴别码容易被重放攻击，尽管有时间戳的设置但是票据在有效期内仍可被重放，因为票据的有效期可能很长而被恶意利用。并且时间戳基于网络上的时钟是同步的这一事实，如果欺骗主机接受一错误的时间，那么重放攻击毫无疑问的能够成功。

第二是猜测口令的攻击，当攻击者可以通过收集尽可能多的票据来进行猜测攻击，如果能够达到一定的数量那么这种攻击方法很容易奏效。

第三是恶意软件的问题，Kerberos协议依赖于Kerberos软件可以信赖的事实，如果系统被一个能够完成Kerberos验证的木马所替代，那么用户的身份变很容易被黑客仿冒。

整个流程大体上包含以下3个子过程：

Client向KDC申请TGT（Ticket Granting Ticket）。
Client通过获得TGT向DKC申请用于访问Server的Ticket。
Client最终向为了Server对自己的认证向其提交Ticket。

不过上面的介绍离真正的Kerberos Authentication还是有一点出入。Kerberos整个认证过程通过3个sub-protocol来完成。这个3个Sub-Protocol分别完成上面列出的3个子过程。这3个sub-protocol分别为：

Authentication Service Exchange
Ticket Granting Service Exchange
Client/Server Exchange

下图简单展示了完成这个3个Sub-protocol所进行Message Exchange。

1． Authentication Service Exchange

通过这个Sub-protocol，KDC（确切地说是KDC中的Authentication Service）实现对Client身份的确认，并颁发给该Client一个TGT。具体过程如下：

Client向KDC的Authentication Service发送Authentication Service Request（KRB_AS_REQ）, 为了确保KRB_AS_REQ仅限于自己和KDC知道，Client使用自己的Master Key对KRB_AS_REQ的主体部分进行加密（KDC可以通过Domain 的Account Database获得该Client的Master Key）。KRB_AS_REQ的大体包含以下的内容：

Pre-authentication data：包含用以证明自己身份的信息。说白了，就是证明自己知道自己声称的那个account的Password。一般地，它的内容是一个被Client的Master key加密过的Timestamp。
Client name & realm: 简单地说就是Domain name/Client
Server Name：注意这里的Server Name并不是Client真正要访问的Server的名称，而我们也说了TGT是和Server无关的（Client只能使用Ticket，而不是 TGT去访问Server）。这里的Server Name实际上是KDC的Ticket Granting Service的Server Name。

AS（Authentication Service）通过它接收到的KRB_AS_REQ验证发送方的是否是在Client name & realm中声称的那个人，也就是说要验证发送放是否知道Client的Password。所以AS只需从Account Database中提取Client对应的Master Key对Pre-authentication data进行解密，如果是一个合法的Timestamp，则可以证明发送放提供的是正确无误的密码。验证通过之后，AS将一份 Authentication Service Response（KRB_AS_REP）发送给Client。KRB_AS_REQ主要包含两个部分：本Client的Master Key加密过的Session Key（SKDC-Client：Logon Session Key）和被自己（KDC）加密的TGT。而TGT大体又包含以下的内容：

Session Key: SKDC-Client：Logon Session Key
Client name & realm: 简单地说就是Domain name/Client
End time: TGT到期的时间。

Client通过自己的Master Key对第一部分解密获得Session Key（SKDC-Client：Logon Session Key）之后，携带着TGT便可以进入下一步：TGS（Ticket Granting Service）Exchange。

2． TGS（Ticket Granting Service）Exchange

TGS（Ticket Granting Service）Exchange通过Client向KDC中的TGS（Ticket Granting Service）发送Ticket Granting Service Request（KRB_TGS_REQ）开始。KRB_TGS_REQ大体包含以下的内容：

TGT：Client通过AS Exchange获得的Ticket Granting Ticket，TGT被KDC的Master Key进行加密。
Authenticator：用以证明当初TGT的拥有者是否就是自己，所以它必须以TGT的办法方和自己的Session Key（SKDC-Client：Logon Session Key）来进行加密。
Client name & realm: 简单地说就是Domain name/Client。
Server name & realm: 简单地说就是Domain name/Server，这回是Client试图访问的那个Server。

TGS收到KRB_TGS_REQ在发给Client真正的Ticket之前，先得整个 Client提供的那个TGT是否是AS颁发给它的。于是它不得不通过Client提供的Authenticator来证明。但是 Authentication是通过Logon Session Key（SKDC-Client）进行加密的，而自己并没有保存这个Session Key。所以TGS先得通过自己的Master Key对Client提供的TGT进行解密，从而获得这个Logon Session Key（SKDC-Client），再通过这个Logon Session Key（SKDC-Client）解密Authenticator进行验证。验证通过向对方发送Ticket Granting Service Response（KRB_TGS_REP）。这个KRB_TGS_REP有两部分组成：使用Logon Session Key（SKDC-Client）加密过用于Client和Server的Session Key（SServer-Client）和使用Server的Master Key进行加密的Ticket。该Ticket大体包含以下一些内容：

Session Key：SServer-Client。
Client name & realm: 简单地说就是Domain name/Client。
End time: Ticket的到期时间。

Client收到KRB_TGS_REP，使用Logon Session Key（SKDC-Client）解密第一部分后获得Session Key（SServer-Client）。有了Session Key和Ticket，Client就可以之间和Server进行交互，而无须在通过KDC作中间人了。所以我们说Kerberos是一种高效的认证方式，它可以直接通过Client和Server双方来完成，不像Windows NT 4下的NTLM认证方式，每次认证都要通过一个双方信任的第3方来完成。

我们现在来看看 Client如果使用Ticket和Server怎样进行交互的，这个阶段通过我们的第3个Sub-protocol来完成：CS（Client/Server ）Exchange。

3． CS（Client/Server ）Exchange

这个已经在本文的第二节中已经介绍过，对于重复发内容就不再累赘了。Client通过TGS Exchange获得Client和Server的Session Key（SServer-Client），随后创建用于证明自己就是Ticket的真正所有者的Authenticator，并使用Session Key（SServer-Client）进行加密。最后将这个被加密过的Authenticator和Ticket作为Application Service Request（KRB_AP_REQ）发送给Server。除了上述两项内容之外，KRB_AP_REQ还包含一个Flag用于表示Client是否需要进行双向验证（Mutual Authentication）。

Server接收到KRB_AP_REQ之后，通过自己的Master Key解密Ticket，从而获得Session Key（SServer-Client）。通过Session Key（SServer-Client）解密Authenticator，进而验证对方的身份。验证成功，让Client访问需要访问的资源，否则直接拒绝对方的请求。

对于需要进行双向验证，Server从Authenticator提取Timestamp，使用Session Key（SServer-Client）进行加密，并将其发送给Client用于Client验证Server的身份。