Kerberos安全认证原理

目录

1、Kerberos是什么

2、主要角色

3、基本概念

4、认证过程

4.1 初始验证

4.2 获取服务票据

4.3 服务验证

5、环境假设

6、局限性

7、相关命令

参考文档：

协议： 协议

主要命令： 主要命令

1、Kerberos是什么

    Kerberos是一种一种网络身份验证协议，只包括验证环节，不负责授权。它旨在通过使用密钥加密技术为客户端/服务器应用程序提供强身份验证。

    用户只需输入一次身份验证信息，就可凭借此验证获得的票据授予票据（ticket-granting ticket）访问多个接入Kerberos的服务，即SSO（Single Sign On，单点登录）。

    在Kerberos认证中，最主要的问题是如何证明“你是你”的问题，如当一个Client去访问Server服务器上的某服务时，Server如何判断Client是否有权限来访问自己主机上的服务，同时保证在这个过程中的通讯内容即使被拦截或篡改也不影响通讯的安全性，这正是Kerberos解决的问题。

2、主要角色

    在Kerberos协议中主要是有三个角色的存在：

  1. 访问服务的Client
  2. 提供服务的Server
  3. KDC（Key Distribution Center）密钥分发中心

    KDC服务默认会安装在一个域的域控中，而Client和Server为域内的用户或者是服务，如HTTP服务，SQL服务等。KDC服务作为客户端和服务器端信赖的第三方，为其提供初始票据（initial ticket）服务和票据授予票据（ticket-granting ticket）服务，前半部分被称为AS，后半部分被称为TGS：

  • AS： Authentication Server，认证服务，用来验证Client端的身份，验证通过就会给一张TGT（Ticket Granting Ticket）票给Client。
  • TGS： Ticket Granting Server，许可证服务，用来将AS发送给Client的TGT换取访问Server端的票据ST（Service Ticket）。有的地方也称呼ST为TGS Ticket，或者直接叫Ticket。

3、基本概念

    Kerberos协议相关角色相关的概念：

  • Principal：安全个体，具有唯一命名的客户端或服务器。命名规则：主名称+实例+领域，如sherlocky/admin@EXAMPLE.COM 
  • SS：特定服务的提供端（Service Server），即上述角色分类中的Server
  • KDC：Key Distribution Center，密钥分发中心由AS和TGS组成
    • AS：Authentication Server，认证服务器，KDC的一部分。通常会维护一个包含安全个体及其秘钥的数据库，用于身份认证
    • TGS：Ticket Granting Server，许可证服务器，KDC的一部分，根据客户端传来的TGT发放访问对应服务的票据

    密钥和票据相关的概念：

  • Session key：会话密钥，指两个安全个体之间使用的临时加密秘钥，其时效性取决于单点登录的会话时间长短
  • Ticket：票据，一条包含客户端标识信息、会话密钥和时间戳的记录，客户端用它来向目标服务器认证自己
  • TGT：Ticket Granting Ticket，票据授予票据，包含客户端ID、客户端网络地址、票据有效期以及client/TGS会话密钥
  • Client本地密钥：用户输入的密码，或者keytab文件中的密码。所有使用用户密钥加密的操作，都是将用户密钥hash后再使用的。

    TGT和Ticket的关系：TGT类似于护照，Ticket则是签证，TGT可标识你的身份并允许你获得多个Ticket（签证），每个Ticket对应一个特定的服务，TGT和Ticket同样具有有效期，过期后就需要重新认证。

4、认证过程

    Kerberos的认证过程可细分为三个阶段：

  1. 初始验证：客户端向KDC中的AS发送用户信息，以请求TGT
  2. 获取服务票据：客户端拿着之前获得的TGT向KDC中的TGS请求访问某个服务的票据
  3. 服务验证。客户端拿到票据（Ticket）后再到该服务的提供端验证身份，然后使用建立的加密通道与服务通信。

4.1 初始验证

    初始验证的主要目的是客户端向AS请求TGT。

  1. 客户端向AS发送鉴权消息Authenticator1，该动作通常发生在用户初次登陆或使用kinit命令时。
    1. Authenticator1的主要内容：用Client本地密钥hash后加密的时间戳、Client ID、网络地址、加密类型等信息（只有时间戳加密！！！）
  2. AS检查本地数据库是否存在该用户，若存在则返回如下两条信息。这一步AS会验证
    1. SessionKey-as：AS生成的会话密钥，用于Client和TGS之间通信。SessionKey-as是用用户密钥加密过的，用户密钥存储在AS本地数据库中的。这个信息可以验证Client是否可信，只有可信的Client才能获取到用户密钥解密出SessionKey-as。
    2. 票据TGT：TGT中包含客户端ID、客户端网络地址、票据有效期和SessionKey-as，并使用TGS的密钥加密。
    3. Timestamp：时间戳不加密，这是client在上一步发给AS的时间戳。
  3. 当客户端上述两条消息，它会：
    1. 对于加密的SessionKey-as，客户端会用本地密钥进行解密，拿到SessionKey-as，用来和TGS进行后续的会话。这里就相当于AS对客户端的一次验证，只有真正拥有正确用户密钥的客户端才能有机会与AS进行后续会话。
    2. 对于加密的TGT，由于是用TGS的密钥加密的，故Client无法对其解密；
    3. 对于Timestamp：Client会对时间戳进行验证，即和自己发送的时间戳做对比，如果一样，说明AS可以解密出自己密钥加密的信息，是可信的。

    需要注意的是，TGT是给TGS看的，Client只用来透传，是看不到TGT的具体内容的。

4.2 获取服务票据

    获取服务票据的主要目的，是客户端使用加密的TGT向TGS请求获取访问对应服务的票据。

  1. 当客户端要访问某个服务时，会向TGS发送如下两条消息：
    1. TGT和服务ID：由上一步可知，TGT是使用TGS的密钥加密的。
    2. 通过SessionKey-as加密的验证器Authenticator2：Authenticator2的内容是Client的ID和时间戳。
  2. TGS收到上述两条消息后：
    1. 检查KDC数据库中是否存在所需服务，若存在则用自己的密钥尝试对TGT进行解密，这里也是客户端对TGS的反向认证，只有真正拥有正确密钥的TGS才能解密成功。
    2. TGS解密TGT得到SessionKey-as、Client Id、Client网络地址、票据有效期等信息，并检查票据是否过期；
    3. 如果请求票据没有过期，TGS会用SessionKey-as解密Authenticator2拿到Client ID和时间戳，并比较这里的用户ID和TGT中解密得到的，如果二者匹配，则向客户端返回：
      1. SessionKey-tgs：通过SessionKey-as加密的会话密钥，该会话密钥是KDC新生成的随机密钥，用于客户端与服务端（SS）的通信加密。
      2. Server Ticket：或简称为Ticket，使用服务的密钥加密的client-server票据，包含用户ID、用户网络地址、票据有效期和SessionKey-tgs。

    和TGT相似，Server Ticket是给服务端看的，但不能让客户端看到，用于服务端对客户端认证。

    这里之所以不用KDC直接把Server Ticket发送给服务端，是因为如果分开发送，由于网络时延的存在，SessionKey-tgs和Server Ticket就不能确保同时到达服务端，考虑一个极端情况，KDC与服务之前的网络临时不通了，那么这段时间服务端就无法收到Server Ticket，导致验证失败，而实际上该客户端是有访问权限的。

4.3 服务验证

    服务验证的主要目的，是客户端与服务端相互验证和通信。

  1. 客户端向服务端发送如下两条消息：
    1. Server Ticket：这是用服务端的密钥加密过，包含用户ID、用户网络地址、票据有效期和SessionKey-tgs。
    2. Authenticator3：通过SessionKey-tgs加密的新的验证器，包含用户ID和时间戳。
  2. 服务端收到消息后：
    1. 用自己的密钥解密Server Ticket，得到Client ID、Client网络地址、票据有效期和SessionKey-tgs。这里是客户端对服务端的验证，只有真正拥有正确密钥的服务端才能正确解密。
    2. 验证票据是否过期；
    3. 用SessionKey-tgs解密Authenticator3，同TGS一样，对分别来自Ticket和Authenticator中的用户ID进行验证，看是否匹配；
    4. 如果匹配成功，则返回确认消息
  3. 客户端用SessionKey-tgs解密确认消息，验证通过。然后客户端与服务端就达到了相互信任，后续的通信都采用SessionKey-tgs加密

5、环境假设

  • 共享密钥：在协议工作前，客户端与KDC，KDC与服务端都确保有了各自的共享密钥。
  • 防Dos攻击：Kerberos协议本身并没有解决Dos攻击防范问题，通常是由系统管理员和用户自己去定期探测并解决这样的攻击。
  • 保障安全个体自身安全：参与到Kerberos协议中的安全个体必须确保其秘钥的安全性，一旦秘钥泄露或被攻击者暴力破解，那么攻击者就能随意地伪装安全个体。
  • 不循环利用Principal的唯一标识：访问控制的常用方式是通过访问控制列表（access control lists，ACLs）来对特定的安全个体进行授权。如果列表中有条记录对应的安全个体A早已被删除，而A的唯一标识却被后来新加的某个个体B再次利用，那么B就会继承之前A对应的权限，这是不安全的。避免这种风险的做法就是不复用Principal的唯一标识。
  • 时钟同步：参与到协议中的主机必须有个时钟相互之间进行“松散同步”，松散度是可配置的。从Kerberos的认证过程可以看到，任何人都可以向KDC请求任何服务的TGT，那攻击者就有可能中途截获正常用户的请求包，然后离线解密拿到TGT。为了防止这种重放攻击，票据（Ticket）会包含时间戳信息，即具有一定的有效期，因此如果主机的时钟与Kerberos服务器的时钟不同步，则认证会失败。在实践中，通常用网络时间协议（Network Time Protocol, NTP）软件来同步时钟。

6、局限性

  • 单点风险：过度依赖于KDC服务，Kerberos协议运转时需要KDC的持续响应，一旦KDC服务挂了，或者KDC数据库被攻破，那么Kerberos协议将无法运转
  • 安全个体自身的安全：Kerberos协议之所以能运行在非安全网络之上，关键假设就是主机自身是安全的，一旦主机上的私钥泄露，攻击者将能轻易的伪装该个体实施攻击

7、相关命令

  • kinit 
  • klist
  • kdestory
  • kpassword
  • krb5-config