随笔-314  评论-209  文章-0  trackbacks-0

1.  Kerberos简介

1.1. 功能

  1. 一个安全认证协议

  2. 用tickets验证

  3. 避免本地保存密码和在互联网上传输密码

  4. 包含一个可信任的第三方

  5. 使用对称加密

  6. 客户端与服务器(非KDC)之间能够相互验证

Kerberos只提供一种功能——在网络上安全的完成用户的身份验证。它并不提供授权功能或者审计功能。

1.2. 概念

首次请求,三次通信方

  • the Authentication Server
  • the Ticket Granting Server
  • the Service or host machine that you’re wanting access to.

 

图 1‑1 角色

其他知识点

  • 每次通信,消息包含两部分,一部分可解码,一部分不可解码
  • 服务端不会直接有KDC通信
  • KDC保存所有机器的账户名和密码
  • KDC本身具有一个密码

2.  3次通信

 

  我们这里已获取服务器中的一张表(数据)的服务以为,为一个http服务。

2.1. 你和验证服务

  如果想要获取http服务,你首先要向KDC表名你自己的身份。这个过程可以在你的程序启动时进行。Kerberos可以通过kinit获取。介绍自己通过未加密的信息发送至KDC获取Ticket Granting Ticket (TGT)。

(1)信息包含

  • 你的用户名/ID
  • 你的IP地址
  • TGT的有效时间

  Authentication Server收到你的请求后,会去数据库中验证,你是否存在。注意,仅仅是验证是否存在,不会验证对错。

  如果存在,Authentication Server会产生一个随机的Session key(可以是一个64位的字符串)。这个key用于你和Ticket Granting Server (TGS)之间通信。

(2)回送信息

  Authentication Server同样会发送两部分信息给你,一部分信息为TGT,通过KDC自己的密码进行加密,包含:

  • 你的name/ID
  • TGS的name/ID
  • 时间戳
  • 你的IP地址
  • TGT的生命周期
  • TGS session key

另外一部分通过你的密码进行加密,包含的信息有

  • TGS的name/ID
  • 时间戳
  • 生命周期
  • TGS session key

 

图 2‑1 第一次通信

  如果你的密码是正确的,你就能解密第二部分信息,获取到TGS session key。如果,密码不正确,无法解密,则认证失败。第一部分信息TGT,你是无法解密的,但需要展示缓存起来。

2.2. 你和TGS

如果第一部分你已经成功,你已经拥有无法解密的TGT和一个TGS Session Key。

(1)    请求信息

 a)  通过TGS Session Key加密的认证器部分:

  • 你的name/ID
  • 时间戳

b)       明文传输部分:

  • 请求的Http服务名(就是请求信息)
  • HTTP Service的Ticket生命周期

c)        TGT部分

  Ticket Granting Server收到信息后,首先检查数据库中是否包含有你请求的Http服务名。如果无,直接返回错误信息。

  如果存在,则通过KDC的密码解密TGT,这个时候。我们就能获取到TGS Session key。然后,通过TGS Session key去解密你传输的第一部分认证器,获取到你的用户名和时间戳。

TGS再进行验证:

  1. 对比TGT中的用户名与认证器中的用户名
  2. 比较时间戳(网上有说认证器中的时间错和TGT中的时间错,个人觉得应该是认证器中的时间戳和系统的时间戳),不能超过一定范围
  3. 检查是否过期
  4. 检查IP地址是否一致
  5. 检查认证器是否已在TGS缓存中(避免应答攻击)
  6. 可以在这部分添加权限认证服务

  TGS随机产生一个Http Service Session Key, 同时准备Http Service Ticket(ST)。

(2)    回答信息

  a)        通过Http服务的密码进行加密的信息(ST):

  • 你的name/ID
  • Http服务name/ID
  • 你的IP地址
  • 时间戳
  • ST的生命周期
  • Http Service Session Key

  b)       通过TGS Session Key加密的信息

  • Http服务name/ID
  • 时间戳
  • ST的生命周期
  • Http Service Session Key

  你收到信息后,通过TGS Session Key解密,获取到了Http Service Session Key,但是你无法解密ST。

 

图 2‑2 第二次通信

2.3. 你和Http服务

  在前面两步成功后,以后每次获取Http服务,在Ticket没有过期,或者无更新的情况下,都可直接进行这一步。省略前面两个步骤。

(1)    请求信息

  a)        通过Http Service Session Key加密部分

  • 你的name/ID
  • 时间戳

  b)       ST

   Http服务端通过自己的密码解压ST(KDC是用Http服务的密码加密的),这样就能够获取到Http Service Session Key,解密第一部分。

服务端解密好ST后,进行检查

  1. 对比ST中的用户名(KDC给的)与认证器中的用户名
  2. 比较时间戳(网上有说认证器中的时间错和TGT中的时间错,个人觉得应该是认证器中的时间戳和系统的时间戳),不能超过一定范围
  3. 检查是否过期
  4. 检查IP地址是否一致
  5. 检查认证器是否已在HTTP服务端的缓存中(避免应答攻击)

(2)    应答信息

a)        通过Http Service Session Key加密的信息

  • Http服务name/ID
  • 时间戳

 

图 2‑3 第三次通信

  你在通过缓存的Http Service Session Key解密这部分信息,然后验证是否是你想要的服务器发送给你的信息。完成你的服务器的验证。

至此,整个过程全部完成。

posted on 2017-04-25 15:56 xzc 阅读(236) 评论(2)  编辑  收藏 所属分类: Javalinux/unixhadoop

评论:
# re: Kerberos简介 2017-04-25 15:57 | xzc
krb5kdc --认证
kadmin --管理账户  回复  更多评论
  
# re: Kerberos简介 2017-04-25 17:44 | xzc
kerberos认证过程(3次通信)
1.次通信
[客户端] -> [明文]用户ID -> [KDC](Authentication Server) -> [KDC密码]TGT(TGS会话密码)+[客户端密码]用户ID/TGS会话密码 -> [客户端]
2.次通信
[客户端] -> [TGS会话密码]用户ID+[明文]HTTP服务名+TGT(TGS会话密码) ->[KDC](Ticket Granting Server) -> [服务端密码]ST(服务会话密码)+[TGS会话密码]HTTP服务名/服务会话密码 -> [客户端]
3.次通信
[客户端] -> [服务会话密码]用户ID+[服务端密码]ST(服务会话密码) -> [服务端] -> [服务会话密码]HTTP服务名 -> [客户端]
注:客户端:java代码客户端
KDC:kerberos认证服务器
服务端:HTTP服务器  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航: