Kerberos

https://web.mit.edu/kerberos/
https://blog.csdn.net/wulantian/article/details/42418231

Kerberos是一种网络认证协议

它被设计用来通过密钥加密算法为客户服务器应用程序提供强认证

从麻省理工的网站上可以获得一份该协议的free实现（此处的free指的是自由软件）

https://web.mit.edu/

Kerberos在许多商业产品上一样很有用处

因特网是一个不安全的地方，许多在网络中使用的应用程序不提供任何安全性。用于sniff密码的工具都被黑客用烂了，因此，在网络中使用明文传输密码的应用程序sucks。更糟糕的是，一些客户服务程序竟然依赖于客户端的诚实（意思就是认为客户是没有恶意的），还有一些其他的客户服务程序依赖于客户端自己限制自己的活动（are you kidding?）而服务器本身并没有做任何强制性的限制。。。。。

一些网站通过firewall来解决他们的网络安全问题，但是造成的破坏最大的网络攻击往往是来源于内部，而且firewall使用起来非常不人性化，对内部用户访问外网的活动也造成了很多限制，也就只是比断网好那么一点而已

Kerberos是由MIT创建的，用于解决上述安全问题。Kerberos使用强加密算法，所以客户端可以直接通过因特网（因特网是不安全的）向服务器提交自己的身份认证信息。在服务器和客户端通过Kerberos 认证完对方的身份之后，它们还可以使用Kerberos来加密它们之间的通信来保障数据的完整性和私密性。（这在商业应用中非常重要的）

Kerberos认证基本原理

现在B想要信任A，那么A就要向B证明自己就是B所信任的那个A，其中一种方法就是A向B展示只有AB两个人知道的一个秘密，这里就涉及到三个问题：

• 如何表示秘密
• A如何传输秘密
• B如何识别秘密

下面基于这三个问题展开说明，我们将上面提到的秘密用一个Key来表示

client为了向server证明自己的身份，需要做以下两件事情：

• 将自己的identity使用明文传递过去
• 将自己的identity使用key作为密钥进行加密传输过去

server收到两组数据，一组没有被加密，一组被加密，直接把加密的数据解密通未加密的明文进行比较即可验证client的身份

这里遗留了一个问题，就是client和server如何拥有相同的key作为密钥来对数据进行加解密

对于一个账户，我们需要使用密码来认证信息，但是又不想直接告诉负责认证的一方自己的明文密码，这里的解决方案就是传输一个使用hash算法对密码进行加密过的hash code来作为认证信息，这样既可以保证密码和hash code的一一对应，又可以保证自己密码的安全，这个hash code一般被称作master key

KDC key distribution center

现在来解决上面的遗留问题，这个密钥需要在server和client之间进行传输，就注定了它只能是一个short-term key，它只在server和client的一次session中有效，所以我们称这个key为session key（skey），那么这个skey是如何被client和server获取到的呢？这时就用到了KDC，它作为kerberos协议中的第三方

在Windows的域环境中，DC就是一个KDC，DC中有一个数据库，存储着所有域中账户的信息，这就意味着它知道所有账户的master key，skey也是由KDC来进行分发的，看一下KDC是如何向client和server分发skey的：

可以看到KDC向client发了两份数据，一份是使用client master key进行加密的，另一份是使用server master key进行加密的（因为KDC知道client和server的密码，自然也就有它们的master key），client使用自己的master key对第一份数据进行解密，即可得到会话使用的密钥skey（Sclient-server）

第二份数据乍看上去好像有点不太对劲，怎么把使用server的master key加密过的数据也发送给了client呢，client并没有server的master key啊，它又解密不了，干嘛发给client呢？？请看下面的解释：

直接将skey发送给server也是可以的，但是会出现下面两个问题：

• 因为server的数量肯定是少于client的数量的，如果KDC直接分发的话，那么server就要维护一个列表，在上面记录每一个client和skey的对应关系，然后当client的认证数据包到了之后找到对应于该client的skey对认证信息进行解密，但是如果让client通知server，就免去了server查表的过程

• 有可能client已经收到了skey，但是server还没有收到skey，这样导致无法认证

所以为了保证client的身份能够被正常识别，就由client告知server

Authenticator

单纯地使用一个client和server都知道的key来进行身份的认证是有漏洞的，所以真正的认证过程并没有这么简单，client会提供额外的信息来自证，这些证明身份的信息统一称为Authenticator，Kerberos协议中的Authenticator就是关于client的一些信息（client info）和一个timestamp

这里再遗留两个问题：

• 安全漏洞是啥？
• 为什么使用time stamp？

在此基础，client解密KDC给自己的使用client的master key加密过的skey，获得skey，使用skey加密自己的Authenticator，然后连同KDC发给自己的使用server的master key加密过的skey和client info打成一个数据包发给server，我们称使用server的master key加密过的skey为session ticket

client发送过来的数据包中，包含两个client info，一个是使用server的master key加密过的来自于KDC的client info（这个来自于server绝对信任的第三方），另一个是使用skey加密的来自于client的client info，server通过比较这两个client info，可以证明client的身份，那么time stamp又有啥用呢？？

现在来解释上面遗留的问题：

time stamp在认证过程中的作用以及不使用timestamp会造成的漏洞

先解释一下为什么会出现漏洞吧

如果网络中的攻击者监听并截获到了上面client发送给server的认证数据包，那么攻击者可以直接把认证数据包当成自己的credential重新发送给server，也可以获得认证，timestamp就是为了解决这个问题的

server在接收到client发送过来的数据包之后，会优先提取出来自client的timestamp信息，通当前时间进行比较，如果差值超出了可接受时间（5min），则不进行后续的身份认证，直接拒绝客户请求

其实这个我是从上面链接的博客看的，有些知识点的确很合理，但是就时间戳的讲解来说，我有点弄不明白，按照博主的说法，攻击这只要在5分钟之内解惑并转发数据包即可，那样的话，时间戳还有啥用？？？

双向认证

上面一直在说server对client的认证，但client对server的认证在某些场景下也是很有必要的，如果访问倒了而已伪装的服务器，并向其发送了重要的信息，将会造成或大或小的损失，具体实现方式是client在向server发送数据包的时候带上了一个flag，表示要求对server的身份进行认证，server知道后会把从client接收到的数据包中的timestamp提取出来使用skey加密回送给client，client收到后解密并和自己原来的timestamp比对，一致则认为自己在访问所期望的server，这里主要是为了防止攻击者通过截获数据包来冒充server，因为timestamp是被skey加密的，但是如果攻击者不知道server的密码的话，是无法获得skey的，也就无法冒充server了，但是如果攻击者得到了server的密码，那么就存在伪装server的可能性了

Ticket Granting Service

说到底，client要想获得server的认证，就必须向其提交从KDC获取到的使用server的mastar key加密过的client info + skey（Session Ticket），这个ticket由一个双方都信任的Ticket颁发机构–KDC负责生成

Ticket Granting Ticket--TGT，这个Ticket也是由KDC负责分发的，client在从KDC获得session ticket之前，需要先拥有TGT，下面讲解client如何从KDC获得TGT

和client向KDC申请对某个server的访问时的ticket的流程差不多，client告诉kdc，它想要一个TGT，然后KDC发给它两条数据，一条是使用client的master key加密的skey（KDC与client之间的skey），另一条是skey+client info，使用KDC的master key进行加密，以后client再向kdc申请访问server的ticket时直接使用TGT就行了，对与client来说，TGT就是使用KDC的master key加密过的skey+client info，可以看到TGT与skey是关联的，而我们前面说过，skey是一个short term key，skey过期之后，TGT也就是失效了，client用户注销再重新登录之后也会导致skey失效，因此skey又被称作logon session key

下面看一下client如何使用TGT从KDC申请访问某个server的ticket

通过上面这个图片可以看出，client向KDC发送了两个数据包，一个是TGT，另一个是使用skey进行加密的Authenticator，由client生成，包含client info信息，第二个就是之前从KDC申请到的TGT

KDC收到这两个数据包之后，先解密TGT，从而获取到skey和client info，然后再使用skey对Authenticator进行解密，提取出client info，并和TGT中的client info进行比对，两者相同，则client的身份认证成功，然后KDC就会向其分发ticket和skey（用于server和client进行认证）

上面这些就是Kerberos认证的基本过程，总结下来是这样的：

• client向KDC申请TGT
• client使用TGT申请访问某个server的ticket
• client拿着ticket和自己生成的Authenticator向server证明自己的身份

对上面的补充

KDC提供两个服务

• 身份认证服务
  • Authentication Server，简称AS
• 票据授予服务
  • Ticket Granting Server，简称TGS

KDC作为一个第三者，或者受委托人来参与另外两个委托人的通信过程，这另外两个委托人，一般就是用户和服务

用户通过UPN（User Principal Name）来标识自己，注意区分委托人（principal）和原则（principle）

服务通过SPN（Service Principal Name）来标识自己，格式为serviceclass/host_port/serviceName，比如：ldap/dc1.bhusa.com

上面的client向KDC请求TGT的过程中涉及到了KDC的master key，这个master key就是AD中的域控制器中的krbtgt账户的密码的散列值

在windows的认证过程中，并不对TGT的来源进行验证，因此我们如果从域中的某台计算机中导出了TGT，我们可以拿着这个TGT去访问域内的其他资源

黄金票据的伪造原理

黄金票据其实就是TGT，有了伪造的TGT之后，我们就免去了向KDC申请TGT的过程，可以直接申请service ticket