Kerberos

1. 相比kerberos，https可能更为熟悉一点，通过证书和非对称加密的方式，让客户端可以安全的访问服务端，但这仅仅是客户端安全，通过校验，客户端可以保证服务端是安全可靠的，而服务端却无法得知客户端是不是安全可靠的。这也是互联网的一种特性。而kerberos可以支持双向认证，就是说，可以保证客户端访问的服务端是安全可靠的，服务端回复的客户端也是安全可靠的。
   
2. Kerberos简单来说就是一个用于安全认证第三方协议，它采用了传统的共享密钥的方式，实现了在网络环境不一定保证安全的环境下，client和server之间的通信，适用于client/server模型，由MIT开发和实现。
   
3. Kerberos的神秘之处在于，它并不要求通信双方所在的网络环境是安全的，即使通信过程中数据被截取或者篡改依然不会影响它的正常工作，它提供的认证是双向的，不仅能保证Server不被错误的Client使用，同时也能保证Client不使用错误的Server。同时Kerberos又严重依赖于时间（双方的时间一般不能超过5分钟），时间戳也是Kerberos用来保证通信安全的重要手段，这个一般通过通信双方同时访问同一个时间服务器来实现。Kerberos也能达到单点登录的效果，即当Client通过了Kerberos server的认证后，便可以访问多个Real Server。
   
4. 在实际的应有场景中通常有三个角色，即需要访问服务的Client，提供服务的Application Server，以及提供安全认证的第三方Kerberos服务器KDC（Key Distribution Center）
5. 简单使用：

   a，使用密码： kinit name@realm 然后根据提示输入密码即可

   b，使用keytab： kinit -kt /path/to/keytab name@realm

   kinit成功之后你获取的票据就会缓存到本地，可以用klist查看，实例如下：

   Ticket cache: FILE:/tmp/krb5cc_0
   Default principal: [e-mail]

   Valid starting Expires Service principal
   03/13/16 17:08:42 03/14/16 17:08:42 krbtgt/[e-mail]
   renew until 03/11/26 17:08:42

   从中也可以看到过期时间。

   如果你要销毁当前获取的票据，用kdestroy即可。

   当然在kinit之前，server端首先要有你的账号，这就需要管理员使用addprinc命令在Kerberos数据库中添加

6. KDC = AS（认证服务器 负责发放TGT(票据授予票据，包含时间戳)）+TGS（票据授予服务器,负责发放服务票据） 

7. Client master key: KDC中存储的Client的密钥  ——该key也是Client声称的Client的key

   Server master key: KDC中存储的Server的密钥

   Sclient-Server：Client与Server之间的会话密钥

   Client Info：记录了Client本身的Ip等基本信息

   
   

8. 普通kerberos授权过程：

            （1）Client与KDC-AS间的交互——获取TGT

                ① Client向KDC中的AS发送一个报文，报文内容大致为：用户user1需要一张TGT用来访问Server。

                ② AS会验证用户数据库中是否存在该用户。如果存在的话，AS会生成一个用于Client与KDC之间安全通信的会话密钥：SKDC-Clinet key

                        ——交互结果

                        数据包① ：使用Client master key加密的SKDC-Clinet key

                        数据包② （TGT）：使用KDC master key加密的SKDC-Clinet key与Client info

                         ——————————KDC不会维护这个SKDC-Client key，这个key在发送给client后就会删除，以                            ——————————后使用时全靠client提供

            （2）Client对与KDC-AS交互后的数据包的处理

                ① 用自己的Client master key解密数据包①得到会话密钥SKDC-Clinet key

                ② 缓存SKDC-Client key与TGT（TGT与这个key一起失效，该key也会在client log off的时候失效）

               ③ 使用SKDC-Client key加密一个Authenticator(Client info + 时间戳) ，以及自己要访问的server name。即数据包③

                ④ 将数据包③与数据包②传递给KDC-TGS以获取server ticket

            （3）KDC-TGS对Client发送来的数据包的处理

                ① 使用KDC master key解密数据包②，获取会话密钥SKDC-Client key与client info

                ② 使用过程①获取的会话密钥SKDC-Client key解密传来的数据包③，获取Client info与时间戳

               ③ 对比过程①与过程②获取的Client info，对比时间戳的时间是否在有效范围内，从而验证Client的真实性，至此，KDC对Client的认证结束。认证成功后会向Client发送两个数据包

                        数据包④：使用SKDC-Client key加密的Sserver-client key(server与client间的会话密钥)

                        数据包⑤：使用数据包③中指定的server的server master key加密一个Ticket（Sserver-client key与 Client info）

             （4）client对KDC-TGS传来数据包的处理

                ① 使用SKDC-Client key 解密数据包④，得到Sserver-client key

                ② 使用Sserver-client key加密自己的Authenticator(Client info + 时间戳)，以及一个标识是否双向验证的flag ,作为数据包⑥

                ③ 将ticket与数据包⑥发送给server

              （5）server对client传来的数据包的处理

                 ① 使用server master key 解密 ticket，获取Sserver-client key与client info

                 ② 使用Sserver-client key解密数据包⑥，获取client info与时间戳。对比两个client info，验证client

              （6）Server与client交互数据或拒绝请求

• 三个sub-protocol
• Authentication Service Exchange：
• 即过程（1）、（2）
• （1）被称为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。
• （2）被称为KRB_AS_REP
• 本Client的Master Key加密过的Session Key（SKDC-Client：Logon Session Key）
• 被自己（KDC）加密的TGT
  • Session Key: SKDC-Client：Logon Session Key
  • Client name & realm: 简单地说就是Domain name\Client
  • End time: TGT到期的时间。
  
  

• TGS（Ticket Granting Service）Exchange：
• 即过程（3）、（4）
• （3）被称为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。
• （4）被称为KRB_TS_REP
• 使用Logon Session Key（SKDC-Client）加密过用于Client和Server的Session Key（SServer-Client）
• 使用Server的Master Key进行加密的Ticket
  • Session Key：SServer-Client。
  • Client name & realm: 简单地说就是Domain name\Client。
  • End time: Ticket的到期时间

• CS（Client/Server ）Exchange：
• 即过程（5）、（6）
• （5）被称为KRB_AP_REQ
  • SServer-Client加密过的Authenticator
  • Server master key加密的Ticket
  • Flag
• （6）被称为KRB_AP_REP

• kerberos双向认证的实现：
• Server对Client的验证：在上面的授权过程中已经体现，不再赘述
• Client对Server的验证：在数据包③中会有一个flag标识是否需要认证，当需要认证时，server会使用会话密钥对时间戳进行加密形成数据包④，回传给client端。client在接收到数据包④后，会使用会话密钥解密数据包④，取得时间戳，若这个时间戳与原来的时间戳一致，则验证了server的真实性。

• 增加了user2user sub-protocol的kerberos:
• 普通的kerberos仍然在使用server master key这个long-term key来完成加密解密过程，一个long-term的key的安全性在面临网络传输时一定是低于一个short-term key
1. AS Exchange：Client通过此过程获得了属于自己的TGT，有了此TGT，Client可凭此向KDC申请用于访问某个Server的Ticket。
2. 这一步的主要任务是获得封装了Server和KDC的Session Key（SKDC-Server）的属于Server的TGT。如果该TGT存在于Server的缓存中，则Server会直接将其返回给Client。否则通过AS Exchange从KDC获取。
3. TGS Exchange：Client通过向KDC提供自己的TGT，Server的TGT以及Authenticator向KDC申请用于访问Server的Ticket。KDC使用先用自己的Master Key解密Client的TGT获得SKDC-Client，通过SKDC-Client解密Authenticator验证发送者是否是TGT的真正拥有者，验证通过再用自己的Master Key解密Server的TGT获得KDC和Server 的Session Key（SKDC-Server），并用该Session Key加密Ticket返回给Client。
4. C/S Exchange：Client携带者通过KDC和Server 的Session Key（SKDC-Server）进行加密的Ticket和通过Client和Server的Session Key（SServer-Client）的Authenticator访问Server，Server通过SKDC-Server解密Ticket获得SServer-Client，通过SServer-Client解密Authenticator实现对Client的验证。

kerberos的server端会维护一个keytab文件 这个文件里就相当于server的密码，也就相当于server端的server master key