Kerberos03：Kerberos的认证请求过程

发表于

这是我参与11月更文挑战的第27天，活动详情查看：2021最后一次更文挑战

Kerberos认证请求认证过程

  1. KRB_AS_REQ：Client用明文向AS发起请求，请求体为Client Info
  2. KRB_AS_REP：AS通过AD验证用户是否存在，不验证密码正确性，AS生成SKDC-Client与TGS Name用CMK加密后和KDC加密的TGT一起返回，Client密码不对则解不开CMK加密部分
  3. KRB_TGT_REQ：Client对Server进行请求，获得KDC加密的Server的TGT(内含SKDC-Server)对于Server来说，可以像Client一样通过AS Exchange获得和KDC之间的SessionKey以及Server的TGT，获得这个TGT后 Server会缓存它，以待Client对它的请求
  4. KRB_TGT_REP：如果Server的TGT存在于缓存，将该TGT返回给Client
  5. KRB_TGS_REQ：Client提供自己的TGT，Server的TGT以及SKDC-Client加密的Authenticator以及要访问的Server请求TGS
  6. KRB_TGS_REP：KDC先解密Client的TGT获得SKDC-Client，用此解密Authenticator和TGT中Client Info对比，TimeStamp与系统时间对比(PRE_AUTH_FAILED)。通过后再解密Server的TGT获得SKDC-Server来加密Session Ticket和SKDC-Client加密的SServer-Client一起返回给Client
  7. KRB_AP_REQ：Client用Session Ticket和SServer-Client加密的Authenticator请求，包含一个Flag是否启用双向认证
  8. KRB_AP_REP：Server用SKDC-Server解密Session Ticket，用SServer-Client解密Auth，对比Client Info和Time，if Flag：Server提取Auth中的TimeStamp，并用SServer-Client加密返回给Client

认证总结

  1. Session-Key是参与的双方都拥有的，KDC颁发，想让对方解密的信息都用Session-key加密
  2. TGT都是KDC加密，Session Tikcet是SKDC-Server加密。Server的TGT是为了提供SKDC-Server
  3. Authenticator (ClientInfo+TimeStamp)：为有效的证明自己提供证据，用请求者和被请求者的Session加密
    Client Info包含：Client-Name(Principle)，IP，TGT有效时间/生命周期
    TGT包含：Client Info+ Session key
    Session Ticket包含：Client和Server的principal、ip、st生命周期、SServer-Client
  4. Long-term Key加密的数据不应该在网络中传递，所以都替换成Short-term key(Session Key)
  5. TGS：可以在这里添加权限认证服务
  6. Client Master Key：用户输入的密码或kerberos.keytab文件中的密码hash生成：为了加密①请求
  7. 一个TGT可以让Client获取多个Server的Session Ticket，TGT和每个Ticket都具有有效期，TGT要是过期了申请的Session Ticket也过期了，在Session Ticket未过期情况下，Client直接可以与Server验证

为什么KDC不直接将Session-Key发给server

  1. Server需要维护一个Session-Key的列表
  2. Session-Key可能等Client去认证还没到Server
  3. KDC都是从TGT获取Session-key来解密

Master Key从哪里来

从Domain的Account Database中提取Client和Server的Master Key

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

0%