9.8. Kerberos

9.8.1. 简介

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知道。

9.8.2. 基本概念

  • 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 给用户以访问其他的服务器

    • 授权和访问控制服务

9.8.3. 简化的认证过程

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

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

    2. 给服务器端的票据,用服务器的密码加密,内容为随机密码,session,client_principal

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

  4. 服务器首先用自己的密码解开票据,拿到SessionKey Kc,s,然后用Kc,s解开Authenticator,并做如下检查
    1. 检查Authenticator中的时间戳是不是在当前时间上下5分钟以内,并且检查该时间戳是否首次出现。如果该时间戳不是第一次出现,那说明有人截获了之前客户端发送的内容,进行Replay攻击。

    2. 检查checksum是否正确

    3. 如果都正确,客户端就通过了认证

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

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

9.8.4. 完整的认证过程

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

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

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

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

  2. AS收到请求之后,随机生成一个密码Kc, s(session key), 并生成以下两个票据返回给客户端:
    1. 给客户端的票据,用客户端的密码加密,内容为随机密码,session,tgs_principal

    2. 给tgs的票据,用tgs的密码加密,内容为随机密码,session,client_principal

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

    2. 给tgs的票据同时发给服务器

    3. server_principal

  4. TGS首先用自己的密码解开票据,拿到SessionKey Kc,s,然后用Kc,s解开Authenticator,并做如下检查
    1. 检查Authenticator中的时间戳是不是在当前时间上下5分钟以内,并且检查该时间戳是否首次出现。如果该时间戳不是第一次出现,那说明有人截获了之前客户端发送的内容,进行Replay攻击。

    2. 检查checksum是否正确

    3. 如果都正确,客户端就通过了认证

  5. tgs生成一个session key组装两个票据给客户端
    1. 用客户端和tgs的session key加密的票据,包含新生成的session key和server_principal

    2. 用服务器的密码加密的票据,包括新生成的session key和client principal

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

    2. 给服务器的票据

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

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

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

9.8.5. 优缺点

9.8.5.1. 优点

  • 密码不易被窃听

  • 密码不在网上传输

  • 密码猜测更困难

  • 票据被盗之后难以使用,因为需要配合认证头来使用

9.8.5.2. 缺点

  • 缺乏撤销机制

  • 引入了复杂的密钥管理

  • 需要时钟同步

  • 伸缩性受限

9.8.6. 参考链接

9.8.6.1. 规范

9.8.6.2. 攻击