Kerberos安全机制-kinit

一、Kerberos协议

Kerberos（具体可参考RFC1510）是一种网络身份验证的协议（注意它只包括验证环节，不负责授权），用户只需输入一次身份验证信息，就可凭借此验证获得的票据授予票据（ticket-granting ticket）访问多个接入Kerberos的服务，即SSO（Single Sign On，单点登录）。

1.基本概念

Principal：安全个体，具有唯一命名的客户端或服务器。命名规则：主名称+实例+领域，如本文开头中的sherlocky/admin @EXAMPLE.COM
Ticket：票据，一条包含客户端标识信息、会话密钥和时间戳的记录，客户端用它来向目标服务器认证自己
Session key：会话密钥，指两个安全个体之间使用的临时加密秘钥，其时效性取决于单点登录的会话时间长短
AS：认证服务器（Authentication Server），KDC的一部分。通常会维护一个包含安全个体及其秘钥的数据库，用于身份认证
SS：特定服务的提供端（Service Server）
TGS：许可证服务器（Ticket Granting Server），KDC的一部分，根据客户端传来的TGT发放访问对应服务的票据
TGT：票据授予票据（Ticket Granting Ticket），包含客户端ID、客户端网络地址、票据有效期以及client/TGS会话密钥
KDC：Key分发中心（key distribution center），是一个提供票据（tickets）和临时会话密钥（session keys）的网络服务。KDC服务作为客户端和服务器端信赖的第三方，为其提供初始票据（initial ticket）服务和票据授予票据（ticket-granting ticket）服务，前半部分有时被称为AS，后半部分有时则被称为TGS。

关于概念的一点补充，博文Kerberos 服务的工作原理中对于TGT和Ticket给出了巧妙的比喻：TGT类似于护照，Ticket则是签证，而访问特定的服务则好比出游某个国家。与护照一样，TGT可标识你的身份并允许你获得多个Ticket（签证），每个Ticket对应一个特定的服务，TGT和Ticket同样具有有效期，过期后就需要重新认证。

2.认证过程
Kerberos的认证过程可细分为三个阶段：初始验证、获取服务票据和服务验证。第一阶段主要是客户端向KDC中的AS发送用户信息，以请求TGT，然后到第二阶段，客户端拿着之前获得的TGT向KDC中的TGS请求访问某个服务的票据，最后阶段拿到票据（Ticket）后再到该服务的提供端验证身份，然后使用建立的加密通道与服务通信。

2.1 初始验证
此过程是客户端向AS请求获取TGT：

客户端向AS发送自身用户信息（如用户ID），该动作通常发生在用户初次登陆或使用kinit命令时
AS检查本地数据库是否存在该用户，若存在则返回如下两条信息：
消息A：使用用户密钥加密的Client/TGS会话密钥，我们称之为SK1。其中用户密钥是通过对该用户在数据库中对应的密码hash生成的
消息B：使用TGS的密钥加密的TGT（包含客户端ID、客户端网络地址、票据有效期和SK1）
当客户端收到消息A和B时，它会尝试用本地的用户密钥（由用户输入的密码或kerberos.keytab文件中的密码hash生成）对A进行解密，只有当本地用户密钥与AS中对应该用户的密钥匹配时才能解密成功。对A解密成功后，客户端就能拿到SK1，才能与TGS进行后续的会话，这里就相当于AS对客户端的一次验证，只有真正拥有正确用户密钥的客户端才能有机会与AS进行后续会话。而对于消息B，由于它是由TGS的密钥加密的，故无法对其解密，也看不到其中的内容。

2.2 获取服务票据
此过程则是客户端向TGS请求获取访问对应服务的票据：

当客户端要访问某个服务时，会向TGS发送如下两条消息：

消息C：消息B的内容（即加密后的TGT）和服务ID 消息D：通过SK1加密的验证器（Authenticator，包括用户ID和时间戳）
TGS收到消息C和D后，首先检查KDC数据库中是否存在所需服务，若存在则用自己的TGS密钥尝试对C中的消息B进行解密，这里也是客户端对TGS的反向认证，只有真正拥有正确密钥的TGS才能对B解密，解密成功后就能拿到其中的SK1，然后再用SK1解密消息D拿到包含用户ID和时间戳的Authenticator，通过比较分别来自C和D的用户ID，如果二者匹配，则向客户端返回如下两条消息：

消息E：通过SK1加密的Client/SS会话密钥，该会话密钥是KDC新生成的随机密钥，用于将来客户端（Client）与服务端（SS）的通信加密，我们称之为SK2
消息F：使用服务的密钥加密的client-server票据（Ticket，包含用户ID、用户网络地址、票据有效期和SK2），之所以要用服务的密钥加密，是因为这个Ticket是给服务端看的，但又需要经过客户端传给服务端，且不能让客户端看到。那么就会有人问，为什么KDC不直接把消息E发送给服务端呢，这样岂不省事？问题就在于网络时延，若分开发送，消息E和F就不能确保同时到达服务端，考虑一个极端情况，KDC与服务之前的网络临时不通了，那么这段时间服务端就无法收到消息E，导致验证失败，而实际上该客户端是有访问权限的。通过公钥加密这种方式巧妙地回避了该问题
客户端收到消息后，尝试用SK1解密消息E，得到Client/SS会话密钥SK2

2.3 服务验证
此过程是客户端与服务端相互验证，并通信

客户端向服务端发送如下两条消息：

消息G：即上一步中的消息F——client-server票据

消息H：通过SK2加密的新的验证器（Authenticator，包含用户ID和时间戳）

服务端收到消息后，尝试用自己的密钥解密消息G，这里实际上也是客户端对服务端的一次验证，只有真正拥有正确密钥的服务端才能正确解密，从而有机会拿到Ticket中的SK2，然后再用该SK2解密消息H，同TGS一样，对分别来自Ticket和Authenticator中的用户ID进行验证，如果匹配成功则返回一条确认消息：

消息I：通过SK2加密的新时间戳
客户端尝试用SK2解密消息I，得到新时间戳并验证其正确性，验证通过后，客户端与服务端就达到了相互信任，后续的通信都采用SK2加密，就好比建立了一条加密通道，二者即可享受服务与被服务的乐趣了

3.前提（环境假设）

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

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

二、kinit命令

Kinit命令用于获取和缓存principal（当前主体）初始的票据授予票据（TGT），此票据用于Kerberos系统进行身份安全验证，实际上它是MIT在版权许可的条件下为kerberos协议所研发的免费实现工具MIT Kerberos（当前最新版本为krb5-1.15.1）的一部分，相关的配套命令还有klist、kdestory、kpasswd、krb5-config等等，基本用法如下：

kinit [-V][-l lifetime] [-s start_time][-r renewable_life][-p | -P][-f | -F][-a][-A][-C][-E][-v][-R][-k [-t keytab_file]][-c cache_name][-n][-S service_name][-I input_ccache][-T armor_ccache][-X attribute[=value]][principal]

各选项具体含义都不做介绍了，可参考官网，较常用的方式就如前言所示，根据指定的事先生成的kerberos.keytab文件为指定个体进行验证。验证通过后，就可以像平常一样进行Hadoop系列操作。那么它是如何进行验证的呢？其中的过程和原理又是怎样的？下面要介绍的kerberos协议细节将会回答你的疑惑。