kerveros认证过程
2014-05-19 20:58
190 查看
摘自:http://zh.wikipedia.org/wiki/Kerberos
协议的安全主要依赖于参加者对时间的松散同步和短周期的叫做Kerberos票据的认证声明。 下面是对这个协议的一个简化描述,将使用以下缩写:
AS(Authentication Server)= 认证服务器
TGT(Ticket Granting Ticket)= 票据授权票据,票据的票据
TGS(Ticket Granting Server)= 票据授权服务器
SS(Service Server)= 服务器
其在网络通讯协定中属于显示层。
简单地说,用户先用共享密钥从某认证服务器得到一个身份证明。随后,用户使用这个身份证明与SS通信,而不使用共享密钥。
(注意:此流程使用了对称加密;此流程发生在某一个Kerberos领域中;小写字母c,d,e是客户机发出的消息,大写字母A,B,E,F,G,H是各个服务器发回的消息。)
首先,用户使用客户机(用户自己的机器)上的程序登录:
用户输入用户ID和密码到客户机。
客户机程序运行一个单向函数(大多数为杂凑)把密码转换成密钥,这个就是客户机(用户)的"用户密钥"(K_client)。受信任的AS通过某些安全的途径也获取了与此密钥相同的密钥。
随后,客户机认证(客户机从AS获取票据的票据(TGT)):
客户机向AS发送1条消息(注意:用户不向AS发送密钥(K_client),也不发送密码):
包含用户ID的明文消息,例如"用户Sunny想请求服务"(Sunny是用户ID)
AS检查用户ID有效性,而后返回2条消息:
消息A:用户密钥(K_client)加密后的"客户机-TGS会话密钥"(K_TGS-session)(会话密钥用在将来客户机与TGS的通信(会话)上)
消息B:TGS密钥(K_TGS)加密后的"票据授权票据"(TGT)(TGT包括:客户机-TGS会话密钥(K_TGS-session),用户ID,用户网址,TGT有效期)
客户机用自己的密钥(K_client)解密A,得到客户机-TGS会话密钥(K_TGS-session)。(注意:客户机不能解密消息B,因为B是用TGS密钥(K_TGS)加密的)。
然后,服务授权(客户机从TGS获取票据(T)):
客户机向TGS发送以下2条消息:
消息c:即消息B(K_TGS加密后的TGT),和想获取的服务的服务ID(注意:不是用户ID)
消息d:客户机-TGS会话密钥(K_TGS-session)加密后的"认证符"(认证符包括:用户ID,时间戳)
TGS用自己的密钥(K_TGS)解密c中的B得到TGT,从而得到AS提供的客户机-TGS会话密钥(K_TGS-session)。再用这个会话密钥解密d得到用户ID(认证),而后返回2条消息:
消息E:服务器密钥(K_SS)加密后的"客户机-服务器票据"(T)(T包括:客户机-SS会话密钥(K_SS-session),用户ID,用户网址,T有效期)
消息F:客户机-TGS会话密钥(K_TGS-session)加密后的"客户机-SS会话密钥"(K_SS_session)
客户机用客户机-TGS会话密钥(K_TGS-session)解密F,得到客户机-SS会话密钥(K_SS_session)。(注意:客户机不能解密消息E,因为E是用SS密钥(K_SS)加密的)。
最后,服务请求(客户机从SS获取服务):
客户机向SS发出2条消息:
消息e:即消息E
消息g:客户机-服务器会话密钥(K_SS_session)加密后的"新认证符"(新认证符包括:用户ID,时间戳)
SS用自己的密钥(K_SS)解密e/E得到T,从而得到TGS提供的客户机-服务器会话密钥(K_SS_session)。再用这个会话密钥解密g得到用户ID(认证),而后返回1条消息(确认函:确证身份真实,乐于提供服务):
消息H:客户机-服务器会话密钥(K_SS_session)加密后的"新时间戳"(新时间戳是:客户机发送的时间戳加1)
客户机用客户机-服务器会话密钥(K_SS_session)解密H,得到新时间戳。
客户机检查时间戳被正确地更新,则客户机可以信赖服务器,并向服务器(SS)发送服务请求。
服务器(SS)提供服务。
协议的安全主要依赖于参加者对时间的松散同步和短周期的叫做Kerberos票据的认证声明。 下面是对这个协议的一个简化描述,将使用以下缩写:
AS(Authentication Server)= 认证服务器
TGT(Ticket Granting Ticket)= 票据授权票据,票据的票据
TGS(Ticket Granting Server)= 票据授权服务器
SS(Service Server)= 服务器
其在网络通讯协定中属于显示层。
简单地说,用户先用共享密钥从某认证服务器得到一个身份证明。随后,用户使用这个身份证明与SS通信,而不使用共享密钥。
(注意:此流程使用了对称加密;此流程发生在某一个Kerberos领域中;小写字母c,d,e是客户机发出的消息,大写字母A,B,E,F,G,H是各个服务器发回的消息。)
首先,用户使用客户机(用户自己的机器)上的程序登录:
用户输入用户ID和密码到客户机。
客户机程序运行一个单向函数(大多数为杂凑)把密码转换成密钥,这个就是客户机(用户)的"用户密钥"(K_client)。受信任的AS通过某些安全的途径也获取了与此密钥相同的密钥。
随后,客户机认证(客户机从AS获取票据的票据(TGT)):
客户机向AS发送1条消息(注意:用户不向AS发送密钥(K_client),也不发送密码):
包含用户ID的明文消息,例如"用户Sunny想请求服务"(Sunny是用户ID)
AS检查用户ID有效性,而后返回2条消息:
消息A:用户密钥(K_client)加密后的"客户机-TGS会话密钥"(K_TGS-session)(会话密钥用在将来客户机与TGS的通信(会话)上)
消息B:TGS密钥(K_TGS)加密后的"票据授权票据"(TGT)(TGT包括:客户机-TGS会话密钥(K_TGS-session),用户ID,用户网址,TGT有效期)
客户机用自己的密钥(K_client)解密A,得到客户机-TGS会话密钥(K_TGS-session)。(注意:客户机不能解密消息B,因为B是用TGS密钥(K_TGS)加密的)。
然后,服务授权(客户机从TGS获取票据(T)):
客户机向TGS发送以下2条消息:
消息c:即消息B(K_TGS加密后的TGT),和想获取的服务的服务ID(注意:不是用户ID)
消息d:客户机-TGS会话密钥(K_TGS-session)加密后的"认证符"(认证符包括:用户ID,时间戳)
TGS用自己的密钥(K_TGS)解密c中的B得到TGT,从而得到AS提供的客户机-TGS会话密钥(K_TGS-session)。再用这个会话密钥解密d得到用户ID(认证),而后返回2条消息:
消息E:服务器密钥(K_SS)加密后的"客户机-服务器票据"(T)(T包括:客户机-SS会话密钥(K_SS-session),用户ID,用户网址,T有效期)
消息F:客户机-TGS会话密钥(K_TGS-session)加密后的"客户机-SS会话密钥"(K_SS_session)
客户机用客户机-TGS会话密钥(K_TGS-session)解密F,得到客户机-SS会话密钥(K_SS_session)。(注意:客户机不能解密消息E,因为E是用SS密钥(K_SS)加密的)。
最后,服务请求(客户机从SS获取服务):
客户机向SS发出2条消息:
消息e:即消息E
消息g:客户机-服务器会话密钥(K_SS_session)加密后的"新认证符"(新认证符包括:用户ID,时间戳)
SS用自己的密钥(K_SS)解密e/E得到T,从而得到TGS提供的客户机-服务器会话密钥(K_SS_session)。再用这个会话密钥解密g得到用户ID(认证),而后返回1条消息(确认函:确证身份真实,乐于提供服务):
消息H:客户机-服务器会话密钥(K_SS_session)加密后的"新时间戳"(新时间戳是:客户机发送的时间戳加1)
客户机用客户机-服务器会话密钥(K_SS_session)解密H,得到新时间戳。
客户机检查时间戳被正确地更新,则客户机可以信赖服务器,并向服务器(SS)发送服务请求。
服务器(SS)提供服务。
相关文章推荐
- 用Tomcat服务器配置https双向认证过程实战
- OAuth认证的过程
- flickr的奇怪的认证过程
- psql登录postgresql数据库的认证过程(md5为例)
- wlan 认证过程
- 结合WAS简析J2EE规范中的登录认证和非规范中的注销以及通过filter增加自定义处理过程
- GitHub的认证过程(一)
- 802.11简单认证过程
- hostapd的radius/eap server代码分析(3)-初始化及一次认证过程
- 关于PEAP认证的过程说明
- OAuth认证的过程
- Apache Shiro 认证过程
- IKEv2的认证数据生成过程
- 用Tomcat服务器配置https双向认证过程实战
- SMB的NTLM认证过程与NTLM挑战的编程实现
- 数字证书及其认证过程
- 用Tomcat服务器配置https双向认证过程实战
- SpringSecurity | 源码分析篇 (一) Spring Security认证过程
- DTLS协议中client/server的认证过程和密钥协商过程
- 一个认证的过程