kerberos的as tgs cs认证基本原理

KDC(kerberos Distribution Center)密钥分发中心,维护所有账户的名称和Master Key(key的hash code)。
提供:AS认证服务、TGS票据授予服务
Client 访问 Service需要Kerberos认证过程3个子协议:
1.AS Exchange
2.TGS Exchange
3.CS Exchange
认证过程如下图:
在这里插入图片描述

1.1Authentication Service Exchange
该服务通过KDC的AS服务对Client身份的确认,并颁发给该Client一个TGT服务授权票据。
在这里插入图片描述

Client向KDC AS发送KRB_AS_REQ请求,Client使用自己的Master Key对KRB_AS_REQ的主体部分进行加密(KDC可以通过AD获取该client的master key)KRB_AS_REQ的大体内容:
Pre-authentication data:包含用以证明自己身份的信息。(证明自己知道account的密码)一般是被client的master key加密的Timestamp
Client name&realm:就是Domin name\Client name

Server Name :KDC 的TGS 的server name
当使用Kerberos V5时,用户的密码永远不会通过网络发送,甚至不会以加密的形式发送,Kerberos V5管理期间除外。
在这里插入图片描述

AS通过接收KRB_AS_REQ是否是Client name&realm声称的account,AS只需要通过提取Client对应的master key 对Pre-authentication解密,如果是合法的Timestamp,则可以证明提供了正确的密码。
通过验证后AS将一份Authentication Service Response(KRB_AS_REP)发送给client,KRB_AS_REP主要包含两部分:本Client的Master key 加密的Session key(SKDC-Client:Logon Session Key),被自己(KDC服务krbtgt对应的key,只有KDC解密防止篡改)加密的TGT。TGT包含以下的内容:
Session Key:SKDC-Client:Logon Session Key
Client name&realm:Domin name/Client
End time:TGT到期时间
Client通过自己 的Master key对第一部分解密获取Session key(SKDC-Client:Logon Session Key)之后,携带TGT便可以进入下一步:TGS(Ticket granting Service)Exchange

1.2Ticket Granting Service Exchange
证明持有的TGT是AS颁发,并获取对应服务的票据
在这里插入图片描述

Client向KDC中的TGS发送KRB_TGS_REQ,请求包含:
TGT:client通过AS Exchange获取的TGT被KDC的Master key进行加密。
Authenticator:用来证明当初TGT的拥有者是否是自己,所以它必须以TGT的颁发方(KDC)和自己(client)的Session key(SKDC-Client:Logon Session Key)来进行加密。在Kerberos的Authenticator实际上就是关于Client的一些信息和当前时间的一个Timestamp。
Client name&realm:Domin name/client name
Server name &realm:Domin name/Server ,这次是Client试图访问的Server。

在这里插入图片描述

TGS收到KRB_TGS_REQ颁发Ticket之前会验证Client提供的TGT是否是AS颁发的。通过Authenticator来证明。但是Authenticator是用Logon Session Key(SKDC-Client)加密的,获取Logon Session Key TGS先用自己的Master key解密TGT,从而获取这个logon Session key解密Authenticator进行验证。通过验证向Client 发送KRB_TGS_REP有两部分组成:使用Logon Session key(SKDC-Client)加密用于Client和Server的Session Key(Sserver-Client)、使用Server的Master Key进行加密的Ticket。Ticket大体包含以下内容:
Session Key:Sserver-Client
Client name&realm:Domin name/Client
End time:Ticket的到期时间
Client收到KRB_GTS_REP使用Logon Session Key(SKDC-Client)解密第一部分获取Session key(SServer-Client)。有了Session Key和Ticket,Client 就可以和Server进行交互。

1.3Client/Server Exchange
证明自己就是Ticket的合法所有者
在这里插入图片描述

Client 通过TGS Exchange获取Client和Server的Session key,随后就是证明自己就是ticket的真正所有者的Authenticator,并使用Session key(SServer-Client)进行加密。最后将Authenticator和Ticket作为KRB_AP_REQ发送给server。

Server接受到KRB_AP_REQ之后,通过自己的master key解密Ticket 从而获取Session key。通过session key解密Authentictor,进行身份验证。验证成功让Client访问需要的资源,否则拒绝对方访问请求。

Kerberos认证解决的是"如何证明我就是我的问题"。在Kerberos认证过程中,涉及到三个角色:客户端(C)、认证服务器(AS)和票据授予服务器(TGS)。整个认证过程可以分为以下几个步骤: 1. 客户端向认证服务器发送身份认证请求。请求中包括客户端的用户名和所需服务的标识。 2. 认证服务器验证客户端的身份,并生成一个临时的Session Key(会话密钥)和票据授予票据(TGT)。TGT是使用认证服务器的私钥加密的,并且只有TGS才能解密。 3. 认证服务器将TGT发送给客户端。客户端收到TGT后,使用自己的密码解密TGT,获取Session Key,并将Session Key保存在本地。 4. 客户端向TGS发送服务票据请求。请求中包括TGT、目标服务的标识和客户端的身份。 5. TGS验证客户端的身份和TGT的有效性,如果通过验证,TGS生成一个临时的服务票据,并使用目标服务的密钥加密该票据。 6. TGS将服务票据发送给客户端。客户端收到服务票据后,使用Session Key解密票据,获取服务票据和目标服务的密钥。 7. 客户端向目标服务发送服务请求。请求中包括服务票据。 8. 目标服务使用自己的密钥解密服务票据,验证票据的有效性。如果验证通过,目标服务向客户端发送一个挑战,客户端使用Session Key对挑战进行加密并发送给目标服务。 9. 目标服务使用自己的密钥解密客户端的响应,并验证响应的正确性。如果验证通过,目标服务确认客户端的身份,并提供所请求的服务。 整个Kerberos认证过程中,使用了多次通信和临时生成的Session Key来确保安全性。认证服务器的数据库中存储了具有Kerberos认证权限的用户和网络服务的信息,用于验证对象的身份和权限。通过这种方式,Kerberos实现了"限权"的认证协议。 请参考上面提供的引用、和来获得更多关于Kerberos认证的详细信息。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值