Kerberos简介

Posted 2023-04-28

参考技术A 简要大概地说一下Kerberos是如何工作的：

实际的过程要比刚才描述的复杂得多。用户过程也会根据具体执行有一些改变。

麻省理工研发了Kerberos协议来保护Project Athena提供的网络服务器。这个协议以希腊神话中的人物Kerberos（或者Cerberus）命名，他在希腊神话中是Hades的一条凶猛的三头保卫神犬。目前该协议存在一些版本，版本1-3都只有麻省理工内部发行。

Kerberos版本4的主要设计者Steve Miller和Clifford Neuman，在1980年末发布了这个版本。这个版本主要针对Project Athena。版本5由John Kohl和Clifford Neuman设计，在1993年作为RFC 1510颁布（在2005年由RFC 4120取代），目的在于克服版本4的局限性和安全问题。

麻省理工在版权许可的情况下，制作了一个Kerberos的免费实现工具，这种情况类似于BSD。在2007年，麻省理工组成了一个Kerberos协会，以此推动Kerberos的持续发展。

因为使用了DES加密算法（用56比特的密钥），美国出口管制当局把Kerberos归类为军需品，并禁止其出口。一个非美国设计的Kerberos版本4的实现工具KTH-KRB由瑞典皇家理工研制，它使得这套系统在美国更改密码出口管理条例（2000年）前，在美国境外就可以使用。瑞典的实现工具基于一个叫做eBones的版本，而eBones基于麻省理工对外发行的基于Kerberos版本4的补丁9的Bones（跳过了加密公式和对它们的函数调用）。这些在一定程度上决定了Kerberos为什么没有被叫做eBones版。Kerberos版本5的实现工具，Heimdal，基本上也是由发布KTH-KRB的同一组人发布。

Windows2000和后续的操作系统都默认Kerberos为其默认认证方法。RFC 3244记录整理了微软的一些对Kerberos协议软件包的添加。RFC4757"微软Windows2000Kerberos修改密码并设定密码协议"记录整理了微软用RC4密码的使用。虽然微软使用了Kerberos协议，却并没有用麻省理工的软件。
苹果的Mac OS X也使用了Kerberos的客户和服务器版本。

Red Hat Enterprise Linux4 和后续的操作系统使用了Kerberos的客户和服务器版本。

IETF Kerberos的工作小组在2005年更新了说明规范，最近的更新包括：

"加密和校验和细则"（RFC 3961）

"针对Kerberos版本5的高级加密算法（AES）加密"（RFC 3962）

Kerberos版本5说明规范的新版本"Kerberos网络认证服务（版本5）"（RFC 4120）。这个版本废弃了早先的RFC 1510，用更细化和明确的解释说明了协议的一些细节和使用方法。

GSS-API的一个新版本"Kerberos版本5 普通的安全服务应用软件交互机制：版本2"（RFC 4121）

CDH升级所使用的的应该是Kerberos的版本5

Kerberos认证原理简介

1.1 What is Kerberos

1.1.1 简单介绍
　　Kerberos是一个用于鉴定身份（authentication）的协议， 它采取对称密钥加密（symmetric-key cryptography），这意味着密钥不会在网络上传输。在Kerberos中，未加密的密码（unencrypted password）不会在网络上传输，因此攻击者无法通过嗅探网络来偷取用户的密码。

　　Kerberos利用对称加密和受信任的第三方（即KDC, key distribution center）来鉴别要求使用网络服务的用户的身份。所有有KDC和secondary KDC管理的主机构成了一个域（realm）。

　　当一个用户的身份通过了KDC的验证后，KDC会向该用户发送一个证书/票据（该证书/票据是与这次会话绑定的），其他kerberized services会在该用户的主机上搜索该ticket，而不是要求用户使用密码来验证他的身份。
1.1.2 关于Kerberos的一些概念
Principal
一个用户会以一个独一无二的身份来被KDC认证，该身份被称为principal。一个Principal由三个部分组成：primary, instance以及realm，其组成形式为primary/instance@realm。
primary : 可以是OS中的username，也可以是service name；
instance : 用于区分属于同一个user或者service的多个principals，该项为optional；
realm : 类似于DNS中的domain，定义了一组principals
1.1.3 认证过程
　　1、当用户在一个kerberos-aware网络中登录到他的workstation之后，authentication server将向KDC发送一个TGT请求（a request for a ticket-granting ticket），而他的principal将作为其中的组成部分。该请求可以由登录程序来负责发送（这样该过程对用户透明），也可以在用户登录后通过执行kinit来发送。

　　2、KDC在其数据库中检查该pricipal。

　　3、如果找到了该principal，则KDC将创建一个TGT，并用user key进行加密，然后将加密后的TGT发送给该用户。这里，user key并不是用户的密码，而是由用户密码计算而来（例如hash）。

　　4、用户所在主机的Kerberos client的登录程序或者kinit程序在收到加密的TGT后，用该用户的user key进行解密。user key只会在client主机上被使用，绝不会在网络上传输。KDC发送的ticket将被保存在一个本地文件中（credentials cache），它可以被kerberized services查验。

　　5、用户的身份验证完成后，servers（运行着kerberized applciations & services）可以查验被识别的principals及其keys（这将被保存在keytab中），而不必用kinit来查验。

　　TGT有一个可设定的失效期（通常为10~24小时），这会被保存在client所在主机的credential cache中。在ticket过期之前，用户在请求kerberized services的服务时不需要再次输入用户密码，除非他们登出后再登录。

　　每当用户需要访问一个network service时，client会利用TGT向TGS（ticket-granting server）请求获得针对该特定网络服务的一个新的ticket。之后，用户可以利用该service ticket来向该network service实现authentication。
1.1.4 How Kerberos works
　　KDC就是受信任的第三方（trusted third party arbitrator），KDC上运行着2个重要的Kerberos daemons，即 kadmind 和 krb5kdc。
　　Kadmind: 这是管理Kerberos server的进程，一个名为kadmin 的程序使用 kadmind 来维护principal database和policy configuration。
　　Krb5kdc: 在Kerberos authentication的过程中担负trusted third party arbitrator的职责。

1.2 认证原理
1.2.1 知识准备
　　为了使读者更加容易理解，在这里我们先给出两个重要的概念：
　　▪ Long-term Key/Master Key：在Security的领域中，有的Key可能长期内保持不
变，比如你在密码，可能几年都不曾改变，这样的Key、以及由此派生的Key被称为Long-term Key。对于Long-term Key的使用有这样的原则：被Long-term Key加密的数据不应该在网络上传输。原因很简单，一旦这些被Long-term Key加密的数据包被恶意的网络监听者截获，在原则上，只要有充足的时间，他是可以通过计算获得你用于加密的Long-term Key的——任何加密算法都不可能做到绝对保密。

　　在一般情况下，对于一个Account来说，密码往往仅仅限于该Account的所有者知晓，甚至对于任何Domain的Administrator，密码仍然应该是保密的。但是密码却又是证明身份的凭据，所以必须通过基于你密码的派生的信息来证明用户的真实身份，在这种情况下，一般将你的密码进行Hash运算得到一个Hash code, 我们一般管这样的Hash Code叫做Master Key。由于Hash Algorithm是不可逆的，同时保证密码和Master Key是一一对应的，这样既保证了你密码的保密性，又同时保证你的Master Key和密码本身在证明你身份的时候具有相同的效力。
　　▪ Short-term Key/Session Key：由于被Long-term Key加密的数据包不能用于网络传送，所以我们使用另一种Short-term Key来加密需要进行网络传输的数据。由于这种Key只在一段时间内有效，即使被加密的数据包被黑客截获，等他把Key计算出来的时候，这个Key早就已经过期了。
1.2.2 认证详细原理
　　Kerberos实际上一个基于Ticket的认证方式。Client想要获取Server端的资源，先得通过Server的认证；而认证的先决条件是Client向Server提供从KDC获得的一个有Server的Master Key进行加密的Session Ticket（Session Key + Client Info）。可以这么说，Session Ticket是Client进入Server领域的一张门票。而这张门票必须从一个合法的Ticket颁发机构获得，这个颁发机构就是Client和Server双方信任的KDC，同时这张Ticket具有超强的防伪标识：它是被Server的Master Key加密的。对Client来说，获得Session Ticket是整个认证过程中最为关键的部分。
　　为了更好的说明整个Ticket Distribution的过程，我在这里做一个类比。现在的股事很火爆，上海基本上是全民炒股，我就举一个认股权证的例子。有的上市公司在股票配股、增发、基金扩募、股份减持等情况会向公众发行认股权证，认股权证的持有人可以凭借这个权证认购一定数量的该公司股票，认股权证是一种具有看涨期权的金融衍生产品。
而我们今天所讲的Client获得Ticket的过程也和通过认股权证购买股票的过程类似。如果我们把Client提供给Server进行认证的Ticket比作股票的话，那么Client在从KDC那边获得Ticket之前，需要先获得这个Ticket的认购权证，这个认购权证在Kerberos中被称为TGT：Ticket Granting Ticket，TGT的分发方仍然是KDC。
我们现在来看看Client是如何从KDC处获得TGT的：首先Client向KDC发起对TGT的申请，申请的内容大致可以这样表示：“我需要一张TGT用以申请获取用以访问所有Server的Ticket”。KDC在收到该申请请求后，生成一个用于该Client和KDC进行安全通信的Session Key（SKDC-Client）。为了保证该Session Key仅供该Client和自己使用，KDC使用Client的Master Key和自己的Master Key对生成的Session Key进行加密，从而获得两个加密的SKDC-Client的Copy。对于后者，随SKDC-Client一起被加密的还包含以后用于鉴定Client身份的关于Client的一些信息。最后KDC将这两份Copy一并发送给Client。这里有一点需要注意的是：为了免去KDC对于基于不同Client的Session Key进行维护的麻烦，就像Server不会保存Session Key（SServer-Client）一样，KDC也不会去保存这个Session Key（SKDC-Client），而选择完全靠Client自己提供的方式。

　　通过上面的过程，Client实际上获得了两组信息：一个通过自己Master Key加密的Session Key，另一个被Sever的Master Key加密的数据包，包含Session Key和关于自己的一些确认信息。

　　Client通过自己的Master Key对KDC加密的Session Key进行解密从而获得Session Key，随后创建Authenticator（Client Info + Timestamp）并用Session Key对其加密。最后连同从KDC获得的、被Server的Master Key加密过的数据包（Client Info + Session Key）一并发送到Server端。我们把通过Server的Master Key加密过的数据包称为Session Ticket。
　　当Server接收到这两组数据后，先使用他自己的Master Key对Session Ticket进行解密，从而获得Session Key。随后使用该Session Key解密Authenticator，通过比较Authenticator中的Client Info和Session Ticket中的Client Info从而实现对Client的认证。

1.2.3kafka认证过程
　　总结起来也很简单，Broker启动时，需要使用配置文件中的身份和密钥文件向KDC（Kerberos服务器）认证，认证通过则加入Kafka集群，否则报错退出。
Producer（或Consumer）启动后需要经过如下步骤与Broker建立安全的Socket连接：
　　1.Producer向KDC认证身份，通过则得到TGT（票证请求票证），否则报错退出
　　2.Producer使用TGT向KDC请求Kafka服务，KDC验证TGT并向Producer返回SessionKey（会话密钥）和ServiceTicket（服务票证）
　　3.Producer使用SessionKey和ServiceTicket与Broker建立连接，Broker使用自身的密钥解密ServiceTicket，获得与Producer通信的SessionKey，然后使用SessionKey验证Producer的身份，通过则建立连接，否则拒绝连接。

转载：http://www.cnblogs.com/xiaodf/p/5968086.html