UDN-企业互联网技术人气社区

板块导航

浏览  : 913
回复  : 0

[干货] CIFS安全协议之Kerberos

[复制链接]
哥屋恩的头像 楼主
发表于 2016-11-6 17:35:22 | 显示全部楼层 |阅读模式
  大家都知道对于NAS的CIFS 来说,NTLM和Kerberos是两个比较重要的验证方式。今天我们来讨论一下作为CIFS安全认证之一的Kerberos协议。

  Kerberos 是一种依赖于验证技术共享密钥的协议,其基本概念很简单,如果一个秘密只有两个人知道,任何一个人都可以通过他们之间共享的秘密来确定对方的身份。用技术的语言来讲,就是对称加密,互相确认。

  说到这里,可能有人会问,NTLM也是CIFS的安全认证啊,为什么Kerberos会用的更广泛呢?他的优点又在哪呢?相信大家了解了Kerberos的工作原理之后就会清楚了。

  Kerberos认证和我们看电影的过程差不多,主要分三个步骤:

  第一步咨询:用户登陆domain

  第二步买票:用户获得service票据

  第三步来访:使用服务票据访问某服务

z.webp.jpg


  用户登陆domain (Logging into the Domain)

  1. Authentication Server request

  AS_REQ,即上图步骤(1)

  一个用户在一台Client机上第一次登陆时,会有弾框提示输入用户名和密码。这时用户密码信息会通过Hash算法产生一个用户的Long Term Key(LTK),再和用户登陆Client端时的时间戳一起进行加密,然后这个用户验证请求被发送给Kerberos Data Center(KDC),并要求KDC返回一个相应的Ticket Granting

  Ticket(TGT)。

  2. Authentication Server response

  AS_REP,即上图步骤(2)

  KDC在数据库中先找到该用户的密码,并用同样的Hash算法生成一个LTK。 然后KDC通过LTK从预认证信息Preauth包KRB_AR_REQ中解密出用户信息和时间戳, 如果用户信息无误,并且时间戳和目前信息相差在5分钟之内,KDC会认为该用户验证通过。KDC将生成一个TGT,并准备把TGT返回给Client。

  在生成TGT的同时,KDC生成一组随机数作为Logon Session Key,并让他和客户端传来的LTK再次进行加密,产生一个名叫enc-part的信息放在该KRB_AS_REP包中,KDC还会用生成的TGT与能被所有KDC识别的LTK进行加密,再次产生一个enc-part放在TGT的头中,这样就得到了一个只有KDC能解开的TGT,最后把这个TGT加入KRB_AS_REP包中并发送至Client端。

  3. Ticket cache

  Client端收到KRB_AS_REP后会用自己的LTK来解密KRB_AS_REP中的enc-part,这里我们默认会得到KDC选用的随机数Logon Session Key。这时候Client端将会把得到的Logon Session Key和KRB_AS_REP中带有原始时间戳的TGT一起存入票据内存中准备给下面过程使用。

  PS:这时候KDC为了减少自身负担,并没有吧Logon Session Key保存在自己这边,所有只有这个用户在Client端的票据内存里面才有该记录了。

  用户获得service票据(Getting a Service Ticket)

  1. Ticket Granting Server request

  TGS_REQ,即上图步骤(3)

  Client端接下来会拿着TGT去告诉KDC我要访问某服务,并让KDC给他访问该服务的票据(service ticket),以后他就可以拿着这张票据直接访问该服务了. Client端用现在的时间戳和之前存在票据内存中的Logon Session Key进行加密生成Authenticator,然后再把带有原始时间戳的TGT一起打包发送给KDC等待验证。

  2. Ticket Granting Server response

  TGS_REP,即上图步骤(4)

  KDC收到KRB_TGS_REQ后会用自己的LTK解密出TGT,然后看看TGT中的原始时间戳,如果来确定TGT现在还是处于有效的状态,KDC就会从TGT中读取Logon Session Key,并用这个Logon Session Key解密Authenticator来获得第二次记录的时间戳,如果该时间差在5分钟之内,KDC认为验证成功,并将生成一个service ticket。

  PS:Kerberos为了防止重演攻击,特别加入了对时间戳的验证。

  接下来KDC又会生成一组叫做Service Session Key的随机数,并把这组随机数和service ticket中记录的Logon Session Key进行加密,产生一个名叫enc-part的信息放在该KRB_TGS_REP包中,KDC还会用生成的service ticket与能被所有KDC识别的LTK进行加密,再次产生一个enc-part放在TGS的头中,这样就得到了一个只有KDC能解开的service ticket,最后把这个service ticket加入KRB_AS_REP包中并发送至Client端。

  3. Ticket Cache

  Client收到KRB_TGS_REP后,通过票据内存中的Logon Session Key解密enc-part,然后得到KDC生成的Service Session Key。最后把Service Session Key和service ticket一起作为访问目标服务器的Credential存入票据内存中。

  使用服务票据访问某服务(Using the Service Ticket)

  1. Application Server request

  AP_REQ,即上图步骤(5)

  经过上面的两次验证,Client现在就能拿着服务票据去访问该服务了。Client记录下时间戳,并读取内存中的Service Session Key与他进行加密生成新的Authenticator,同时用户还要标记好自己是否需要双向认证 (Mutual

  Authentication),最后再加上之前的服务票据一起发送给该服务的server(在NAS系统中相对应的服务就是CIFS,server就是我们加入domain的CIFS server)。

  2. Application Server response

  AP_REP,即上图步骤(6)

  NAS收到这个加密的KBR_AP_REQ之后,用自己的LTK进行解密。接着server从service ticket里面读出service session Key来解密Authenticator中的时间戳。如果时间差小于5分钟,NAS就允许该用户对他进行访问了,并且为这个Client上的这个用户创建一个security token。

  Kerberos优点:

  虽然上面Kerberos的工作原理稍微有点复杂,不过我们还是能从中看出Kerberos的高效性,相互身份验证以及互操作性的优点。

  高效性:客户端不用每次访问NAS时都去DC验证,而通过查询client credentials就可以验证了。

  相互身份验证:client和server可以互相验证。

  互操作性:微软的Kerberos V5实现是基于IETF的推荐标准规范。这样,Windows Server 2003的Kerberos V5实现就为其他使用Kerberos V5协议的网络的互操作打下了基。

原文作者: EMC中文技术社区  来源:开发者头条
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部