由于最近的项目中要用到kerberos and spnego protocol,查了一些资料,结合网上的资料和对它一定的理解,整理如下,以备后查.(如有不对之处,肯请高手指教)
kerberos是一个很重要的网络认证协议,它实现了在一个非安全的网络环境中,一个实体向另一个实体证实自己的身份,从而以安全的方式进行交流.kerberos protocol已经被广泛应用于各种应用中,最为典型的莫过于windows中的kerberos认证,它在spnego protocol之下,为windows域用户登录提供安全保障.
首先相关名词:
Long term key:就是长期保持不变的key.
Master key:就是Long term key经过Hash运算得到的Hash code.
Short term key:就是只在一定时间内有效的key.有时也叫Session key.
原则上Long term key 是不能在网络上传输的,因为很可能Long term key在传输过程中被人截获,一旦它被截获,原则上只要有足够的时间,就可以被破解.另外,对于一个帐户而言,密码仅限于该用户知道,对于domain的Administrator也应该保密,但由于密码是用户向Administrator证明身份的凭据,所以要基于用户的密码生成来的信息来证明用户的身份,通常做法是对密码进行Hash运算,生成Hash code,这个Hash code就是我们说的Master key.因为Hash Algorithm具有不可逆,同时保证了密码与Master key一一对应的特性,保证了密码的保密性,也保证了Master key可以代表密码作为用户身份的凭证.而作为 Short term key,用来加密在网络上传输的数据,由于它只在一定时间内有效,即使被人截获,等到被破解时,这个key早就过期了.
Client 服务请求者
Server 服务提供者
KDC kerberos distribution certer.在整个认证过程中作为client和server共同信认的第三方.
以windows2003中的Domain为例,Domain Controller扮演着kdc的角色.
下面我来介绍一下这kerberos协议如何实现认证的.
前提:client和server都在kdc上已注册.
第一步 Authentication Service Exchange
第二步 Ticket Granting Service Exchange
第三步 Client/Server Exchange
首先Client向kdc申请server服务,kdc查看server服务是受保护的服务,所以要验证client的身份,这就是第一步,kdc验证client的身份(Authentication Service Exchange).当kdc核实client的身份正确后,会给client一个证明,用这个证明我们可以得到访问server服务的许可证(Ticket),所以我们把这个证明叫做TGT(Ticket Granting Ticket).
当client得到TGT后,用TGT来向kdc索要访问server服务的通行证(Ticket),这就是第二步Ticket Granting Service Exchange.
当client得到通行证(Ticket)后,就与server交互,向server出示通行证(Ticket),即第三步Client/Server Exchange,从可得到server的服务.
以上三步的具体实现要复杂得多,简单介绍如下:
1． Authentication Service Exchange
通过这个Sub-protocol，KDC（确切地说是KDC中的Authentication Service）实现对Client身份的确认，并颁发给该Client一个TGT。具体过程如
下：
Client向KDC的Authentication Service发送Authentication Service Request（KRB_AS_REQ）, 为了确保KRB_AS_REQ仅限于自己和KDC知道，
Client使用自己的Master Key对KRB_AS_REQ的主体部分进行加密（KDC可以通过Domain 的Account Database获得该Client的Master Key）。
KRB_AS_REQ的大体包含以下的内容：
Pre-authentication data：包含用以证明自己身份的信息。说白了，就是证明自己知道自己声称的那个account的Password。一般地，它的内容是
一个被Client的Master key加密过的Timestamp。
Client name & realm: 简单地说就是Domain name\Client Server Name：注意这里的Server Name并不是Client真正要访问的Server的名称，而我们也说
了TGT是和Server无关的（Client只能使用Ticket，而不是TGT去访问Server）。这里的Server Name实际上是KDC的Ticket Granting Service的Server Name。
AS（Authentication Service）通过它接收到的KRB_AS_REQ验证发送方的是否是在Client name & realm中声称的那个人，也就是说要验证发送放是
否知道Client的Password。所以AS只需从Account Database中提取Client对应的Master Key对Pre-authentication data进行解密，如果是一个合法
的Timestamp，则可以证明发送放提供的是正确无误的密码。验证通过之后，AS将一份Authentication Service Response（KRB_AS_REP
）发送给Client。KRB_AS_REQ主要包含两个部分：本Client的Master Key加密过的Session Key（
SKDC-Client：Logon Session Key）和被自己（KDC）加密的TGT。而TGT大体又包含以下的内容
：
Session Key: SKDC-Client：Logon Session Key
Client name & realm: 简单地说就是Domain
name\Client
End time: TGT到期的时间。
Client通过自己的Master Key对第一部分解密获得Session Key（SKDC-Client：Logon Session Key）之后，携带着TGT便可以进入下一步：TGS（
Ticket Granting Service）Exchange。
2． TGS（Ticket Granting Service）Exchange
TGS（Ticket Granting Service）Exchange通过Client向KDC中的TGS（Ticket Granting Service）发送Ticket Granting Service Request
（KRB_TGS_REQ）开始。KRB_TGS_REQ大体包含以下的内容：
TGT：Client通过AS Exchange获得的Ticket
Granting Ticket，TGT被KDC的Master Key进行加
密。
Authenticator：用以证明当初TGT的拥有者是否就是自己，所以它必须以TGT的办法方和自己的Session Key（SKDC-Client：Logon Session Key
）来进行加密。
Client name & realm: 简单地说就是Domain name\Client。
Server name & realm: 简单地说就是Domain name\Server，这回是Client试图访问的那个Server。
TGS收到KRB_TGS_REQ在发给Client真正的Ticket之前，先得整个Client提供的那个TGT是否是AS颁发给它的。于是它不得不通过Client提供的
Authenticator来证明。但是Authentication是通过Logon Session Key（SKDC-Client）进行加密的，而自己并没有保存这个Session Key。所以
TGS先得通过自己的Master Key对Client提供的TGT进行解密，从而获得这个Logon Session Key（SKDC-Client），再通过这个Logon Session
Key（SKDC-Client）解密Authenticator进行验证。验证通过向对方发送Ticket Granting Service Response（KRB_TGS_REP）。这个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: 简单地说就是Domain name\Client。
End time: Ticket的到期时间。
Client收到KRB_TGS_REP，使用Logon Session Key（SKDC-Client）解密第一部分后获得Session Key（SServer-Client）。有了Session Key和
Ticket，Client就可以之间和Server进行交互，而无须在通过KDC作中间人了。所以我们说Kerberos是一种高效的认证方式，它可以直接通
过Client和Server双方来完成，不像Windows NT 4下的NTLM认证方式，每次认证都要通过一个双方信任的第3方来完成。
我们现在来看看 Client如果使用Ticket和Server怎样进行交互的，这个阶段通过我们的第3个Sub-protocol来完成：CS（Client/Server ）
Exchange。
3． CS（Client/Server ）Exchange
Client通过TGSExchange获得Client和Server的Session Key（SServer-Client），随后创建用于证明自己就是Ticket的真正所有者的Authenticator，并使用Session Key（SServer-Client）进行加密。最后将这个被加密过的Authenticator和Ticket作为Application Service Request（KRB_AP_REQ）发
送给Server。除了上述两项内容之外，KRB_AP_REQ还包含一个Flag用于表示Client是否需要进行双向验证（Mutual Authentication）。
Server接收到KRB_AP_REQ之后，通过自己的Master Key解密Ticket，从而获得Session Key（SServer-Client）。通过Session Key（SServer
-Client）解密Authenticator，进而验证对方的身份。验证成功，让Client访问需要访问的资源，否则直接拒绝对方的请求。
对于需要进行双向验证，Server从Authenticator提取Timestamp，使用Session Key（SServer-Client）进行加密，并将其发送给Client用于
Client验证Server的身份。
想要更深入的理解kerberos,请参考官方网站
http://web.mit.edu/Kerberos/