Kerberos认证协议

安全协议:Kerberos认证协议

一、简介

Kerberos由MIT于1988年开发，用于分布式环境中，完成服务器与用户之间的相互认证。设计者的设计初衷是要用Kerberos的三个头来守卫网络之门。三个头分别包括：认证、账目清算和审计。

Kerberos要解决的问题

在一个开放的分布式网络环境中，用户通过工作站访问服务器提供的服务，存在许多问题：

• 工作站上的用户可以冒充另一个用户操作
• 用户可以改变工作站的地址冒充另一台工作站
• 用户可以窃听并回放他人的信息交换，获得对于某种服务的访问权或中断服务的运行
• 使用假冒服务器从而骗得用户的机密信息

Kerberos的解决方案

• 在一个分布式的Client/Server体系的机构中，引入一个可信任的第三方(Kerberos服务器)，让其提供认证服务。
• 使用共享密钥加密技术

Kerberos基本性质

• 安全：使网络窃听者不能获得必要的信息来伪装成另一个客户。
• 可靠：对所有以Kerberos进行控制访问的服务来说，客户无法通过Kerberos服务器的认证就意味着无法获得所需要的服务。
• 透明：用户除了需要输入一个口令外，不必知道认证过程的存在以及细节。
• 可伸缩：可支持大量用户和服务器。

二、协议具体内容

三个重要概念

• 认证服务器（AS）：它将所有用户的口令集中存放在本地数据库中；而且它与每一个应用服务器共享一个唯一的密钥（这些密钥通过物理或其他安全的方式发放）
• 客户端（C）：代替用户与服务器进行信息交换
• 票据（Ticket）：身份或权利的证明
  Ticket由AS以数据报形式发放给C。

一个简单的认证对话

上图就是一个简单的认证对话过程，总共有三步：

1. C → AS : ID_c || P_c || ID_v
2. AS → C ： Ticket
3. C → V : ID_c || Ticket

其中Ticket = E_Kv[ ID_c || AD_c || ID_v]

符号说明：
C ：客户端
AS ：认证服务器
V ：服务（服务器）
ID_c ：在C上的用户标志
ID_v ：在V上的用户标志
P_c ：在C上的用户口令
AD_c ：C的1网络地址
K_v ：AS与V共享的加密密钥
|| ：级联

过程理解

1. C → AS : ID_c || P_c || ID_v
   在这一步中，C向AS发送自己的身份，口令以及要申请的服务。也就是C向AS说，我是谁谁谁，这是我的密码，我要啥啥啥服务，帮我认证一下，给我张票。
2. AS → C ： Ticket
   在这一步中，AS验证C的真实性（验证ID_c 的口令是不是 P_c ）,验证通过就给C发张Ticket，Ticket用AS与V共享的密钥加密了C的身份，C的地址以及V的身份。
3. C → V : ID_c || Ticket
   第三步，C向V发送自己的身份以及票据，请求服务。V收到消息后，得到C的身份以及票据，使用AS与V之间的共享密钥解密后得到票据里的信息，看C是否与Ticket中的C一致

存在的两个最突出的问题

• 用户每次访问一次新的服务就需要一个新的票据，导致用户多次输入口令。
• 用明文传递的用户口令会被窃听

解决方案

• 使用票据许可服务器（TGS Ticket Grant Server）TGS向通过认证的用户发放票据，AS只需认证用户
• Ticket重用，设置生命期，在生命期内票据都可使用，不需频繁申请。

改进的认证对话

改进的认证对话有五步：

• Once per user logon session

1. C → AS ：ID_c || ID_tgs
2. AS → C : E_Kc[Ticket_tgs]
   其中Ticket_tgs = E_Ktgs[ID_c || AD_c || ID_tgs || TS₁ || Lifetime₁]
   符号说明：
   ID_tgs : TGS的标志符
   K_c ：由用户口令导出的密钥
   TS₁ ：时间戳
   Lifetime₁ ：生存期

• Once per type of service

3. C → TGS ：ID_c || ID_v || Ticket_tgs
4. TGS → C ：Ticket_v
   其中Ticket_v = E_Kv[ID_c || AD_c || ID_v || TS₂ || Lifetime₂]
   符号说明：
   K_v ：TGS和服务器共享的密钥

• Once per service session

5. C → V ：ID_c || Ticket_v

过程解释

1. C → AS ：ID_c || ID_tgs
   这一步中，用户只需要将自己的标识符以及TGS的标识符传递给AS，不需要传递明文口令
2. AS → C : E_Kc[Ticket_tgs]
   第二步中，AS使用由C的口令衍生的密钥加密票据，该消息只有AS与C双方之间才能解读，票据当中包含C的标识符，地址，TGS的标识符，时间戳以及生存周期（防止重放攻击），票据的信息由AS与TGS之间的密钥进行加密，这样保证了只有对应的TGS能验证
3. C → TGS ：ID_c || ID_v || Ticket_{tgs
   C将票据以及自己的身份和要申请的服务发送给TGS，TGS验证票据，检查有效期。}
4. TGS → C ：Ticket_v
   验证通过后，TGS向C发送票据，该票据的信息包括了C的标识符，地址，V的标识符，生存周期，时间戳，这些信息经由TGS和服务器之间共享的密钥进行加密
5. C → V ：ID_c || Ticket_v
   最后一步，C凭借票据和身份获取服务

可以看到，在改进的方法中，口令不需在网络上频繁的传输，身份的认真也经过了加密，设置了生存期，在生存期内票据可以重用

存在的问题

• 生存期长短的设置，太长，不太方便保护安全性，敌手窃取到Ticket后就可以在生存期结束前获得合法用户的资源，太短又要多次重复输入口令
• 服务器不能向用户认证自己

解决方案

• 会话密钥（Session Key） 让AS以安全的方式向C和TGS提供同一个会话密钥，然后C向TGS出示用Session Key加密的个人信息 || Ticket 来证明身份。同样，TGS向C核V做同样的事情
• 认证符 使用Session Key加密（用户ID、地址、时间戳）的报文

Kerberos 第四版

具体步骤：

• 认证服务交换：获得票据许可票据

1. C → AS ：ID_c || ID_tgs || TG₁
2. AS → C : E_Kc[K_c,tgs || ID_tgs || TS₂ || Lifetime₂ || Ticket_tgs]
   其中Ticket_tgs = E_Ktgs[K_c,tgs || ID_c || AD_c || ID_tgs || TS₂ || Lifetime₂]
   符号说明：
   K_c,tgs : 由AS生成允许客户端和TGS间安全交换报文

• 票据许可服务交换：获得服务许可票据

3. C → TGS ：ID_v || Ticket_tgs || Authenticator_c
4. TGS → C ：K_c,tgs[K_C,V || ID_v || TS₄ || Ticket_v]
   其中Ticket_v = E_Kv[K_C,V || ID_c || AD_c || ID_v || TS₄ || Lifetime₄]
   Authenticator_c = E_Kc,tgs[ID_c || AD_c || TS₃]
   符号说明：
   Authenticator_c ：由客户端产生认证符，证明票据的有效性

• 客户端/服务器端认证交换：获得服务

5. C → V ： Ticket_v || Authenticator_c
6. V → C ：E_Kv[TS₅ + 1]
   其中：
   Authenticator_c = E_Kc,v[ID_c || AD_c || TS₅]
   第六步可以使C确信不是就回答的重放

过程分析
第四版觉改进的会话多了会话的密钥，每次交换用的密钥都由上一步生成，票据都经过加密再传递给C，儿C向V发送服务请求，V会向C发送加密的数据，这个数据证明服务器不是敌手伪装的。

请求其他域的服务器的服务
先占坑，有空再写。