首页 安全 WEB安全学习笔记 认证机制

# 简介

Kerberos 协议起源于美国麻省理工学院 Athena 项目，基于公私钥加密体制，为分布式环境提供双向验证，在 RFC 1510 中被采纳，Kerberos 是 Windows 域环境中的默认身份验证协议。

简单地说，Kerberos 提供了一种单点登录 (Single Sign-On, SSO) 的方法。考虑这样一个场景，在一个网络中有不同的服务器，比如，打印服务器、邮件服务器和文件服务器。这些服务器都有认证的需求。很自然的，不可能让每个服务器自己实现一套认证系统，而是提供一个中心认证服务器 (Authentication Server, AS) 供这些服务器使用。这样任何客户端就只需维护一个密码就能登录所有服务器。

Kerberos 协议是一个基于票据 (Ticket) 的系统，在 Kerberos 系统中至少有三个角色：认证服务器 (AS)，客户端 (Client) 和普通服务器 (Server)。

认证服务器对用户进行验证，并发行供用户用来请求会话票据的 TGT (票据授予票据)。票据授予服务 (TGS) 在发行给客户的 TGT 的基础上，为网络服务发行 ST (会话票据)。

在 Kerberos 系统中，客户端和服务器都有一个唯一的名字，叫做 Principal。同时，客户端和服务器都有自己的密码，并且它们的密码只有自己和认证服务器 AS 知道。

# 基本概念

  • Principal (安全个体)

    • 被认证的个体，有一个名字 (name) 和口令 (password)

  • KDC (Key Distribution Center)

    • 提供 ticket 和临时的会话密钥的网络服务

  • Ticket

    • 一个记录，用户可以用它来向服务器证明自己的身份，其中包括用户的标识、会话密钥、时间戳，以及其他一些信息。Ticket 中的大多数信息都被加密，密钥为服务器的密钥

  • Authenticator

    • 一个记录，其中包含一些最近产生的信息，产生这些信息需要用到用户和服务器之间共享的会话密钥

  • Credentials

    • 一个 ticket 加上一个秘密的会话密钥

  • Authentication Server (AS)

    • 通过 long-term key 认证用户
    • AS 给予用户 ticket granting ticket 和 short-term key
    • 认证服务

  • Ticket Granting Server (TGS)

    • 通过 short-term key 和 Ticket Granting Ticket 认证用户
    • TGS 发放 tickets 给用户以访问其他的服务器
    • 授权和访问控制服务

# 简化的认证过程

  1. 客户端向服务器发起请求，请求内容是：客户端的 principal，服务器的 principal

  2. AS 收到请求之后，随机生成一个密码 Kc, s (session key), 并生成以下两个票据返回给客户端

    • 给客户端的票据，用客户端的密码加密，内容为随机密码，session，server_principal
    • 给服务器端的票据，用服务器的密码加密，内容为随机密码，session，client_principal

  3. 客户端拿到了第二步中的两个票据后，首先用自己的密码解开票据，得到 Kc、s，然后生成一个 Authenticator，其中主要包括当前时间和 Ts,c 的校验码，并且用 SessionKey Kc,s 加密。之后客户端将 Authenticator 和给 server 的票据同时发给服务器

  4. 服务器首先用自己的密码解开票据，拿到 SessionKey Kc,s，然后用 Kc,s 解开 Authenticator，并做如下检查

    • 检查 Authenticator 中的时间戳是不是在当前时间上下 5 分钟以内，并且检查该时间戳是否首次出现。如果该时间戳不是第一次出现，那说明有人截获了之前客户端发送的内容，进行 Replay 攻击。
    • 检查 checksum 是否正确
    • 如果都正确，客户端就通过了认证

  5. 服务器段可选择性地给客户端回复一条消息来完成双向认证，内容为用 session key 加密的时间戳

  6. 客户端通过解开消息，比较发回的时间戳和自己发送的时间戳是否一致，来验证服务器

# 完整的认证过程

上方介绍的流程已经能够完成客户端和服务器的相互认证。但是，比较不方便的是每次认证都需要客户端输入自己的密码。

因此在 Kerberos 系统中，引入了一个新的角色叫做：票据授权服务 (TGS - Ticket Granting Service)，它的地位类似于一个普通的服务器，只是它提供的服务是为客户端发放用于和其他服务器认证的票据。

这样，Kerberos 系统中就有四个角色：认证服务器 (AS)，客户端 (Client)，普通服务器 (Server) 和票据授权服务 (TGS)。这样客户端初次和服务器通信的认证流程分成了以下 6 个步骤：

  1. 客户端向 AS 发起请求，请求内容是：客户端的 principal，票据授权服务器的 rincipal

  2. AS 收到请求之后，随机生成一个密码 Kc, s (session key), 并生成以下两个票据返回给客户端：

    • 给客户端的票据，用客户端的密码加密，内容为随机密码，session，tgs_principal
    • 给 tgs 的票据，用 tgs 的密码加密，内容为随机密码，session，client_principal

  3. 客户端拿到了第二步中的两个票据后，首先用自己的密码解开票据，得到 Kc、s，然后生成一个 Authenticator，其中主要包括当前时间和 Ts,c 的校验码，并且用 SessionKey Kc,s 加密。之后客户端向 tgs 发起请求，内容包括:

    • Authenticator
    • 给 tgs 的票据同时发给服务器
    • server_principal

  4. TGS 首先用自己的密码解开票据，拿到 SessionKey Kc,s，然后用 Kc,s 解开 Authenticator，并做如下检查

    • 检查 Authenticator 中的时间戳是不是在当前时间上下 5 分钟以内，并且检查该时间戳是否首次出现。如果该时间戳不是第一次出现，那说明有人截获了之前客户端发送的内容，进行 Replay 攻击。
    • 检查 checksum 是否正确
    • 如果都正确，客户端就通过了认证

  5. tgs 生成一个 session key 组装两个票据给客户端

    • 用客户端和 tgs 的 session key 加密的票据，包含新生成的 session key 和 server_principal
    • 用服务器的密码加密的票据，包括新生成的 session key 和 client principal

  6. 客户端收到两个票据后，解开自己的，然后生成一个 Authenticator，发请求给服务器，内容包括

    • Authenticator
    • 给服务器的票据

  7. 服务器收到请求后，用自己的密码解开票据，得到 session key，然后用 session key 解开 authenticator 对可无端进行验证

  8. 服务器可以选择返回一个用 session key 加密的之前的是时间戳来完成双向验证

  9. 客户端通过解开消息，比较发回的时间戳和自己发送的时间戳是否一致，来验证服务器

# 优缺点

# 优点

  • 密码不易被窃听
  • 密码不在网上传输
  • 密码猜测更困难
  • 票据被盗之后难以使用，因为需要配合认证头来使用

# 9.8.5.2. 缺点

  • 缺乏撤销机制
  • 引入了复杂的密钥管理
  • 需要时钟同步
  • 伸缩性受限

# 参考链接

# 规范

  • RFC 1510 The Kerberos Network Authentication Service
  • Kerberos 认证流程详解

# 攻击

  • Delegate to the Top: Abusing Kerberos for arbitrary impersonations and RCE
  • Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol
  • Kerberos Technical Supplement for Windows
  • Cracking Kerberos TGS Tickets Using Kerberoast – Exploiting Kerberos to Compromise the Active Directory Domain