kerberosv4与kerberosv5比较分析.doc

Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术（如：共享密钥）执行认证服务的。Kerberos的组成Kerberos应用程序库：应用程序接口，包括创建和读取认证请求，以及创建safe message 和private message的子程序。加密/解密库：DES等。Kerberos数据库：记载了每个Kerberos 用户的名字，私有密钥，截止信息(记录的有效时间，通常为几年)等信息。数据库管理程序：管理Kerberos数据库KDBM服务器(数据库管理服务器)：接受客户端的请求对数据库进行操作。认证服务器(AS)：存放一个Kerberos数据库的只读的副本，用来完成principle的认证，并生成会话密钥数据库复制软件：管理数据库从KDBM服务所在的机器，到认证服务器所在的机器的复制工作，为了保持数据库的一致性，每隔一段时间就需要进行复制工作用户程序：登录Kerberos，改变Kerberos密码，显示和破坏Kerberos标签（ticket）等工作。Kerberos协议分为两个部分：1 . Client向KDC发送自己的身份信息，KDC从Ticket Granting Service得到TGT(ticket-granting ticket)， 并用协议开始前Client与KDC之间的密钥将TGT加密回复给Client。此时只有真正的Client才能利用它与KDC之间的密钥将加密后的TGT解密，从而获得TGT。（此过程避免了Client直接向KDC发送密码，以求通过验证的不安全方式）2. Client利用之前获得的TGT向KDC请求其他Service的Ticket，从而通过其他Service的身份鉴别。 Kerberos协议的重点在于第二部分，简介如下：1 Client将之前获得TGT和要请求的服务信息(服务名等)发送给KDC，KDC中的Ticket Granting Service将为Client和Service之间生成一个Session Key用于Service对Client的身份鉴别。然后KDC将这个Session Key和用户名，用户地址（IP），服务名，有效期, 时间戳一起包装成一个Ticket(这些信息最终用于Service对Client的身份鉴别)发送给Service， 不过Kerberos协议并没有直接将Ticket发送给Service，而是通过Client转发给Service.所以有了第二步。2 此时KDC将刚才的Ticket转发给Client。由于这个Ticket是要给Service的，不能让Client看到，所以KDC用协议开始前KDC与Service之间的密钥将Ticket加密后再发送给Client。同时为了让Client和Service之间共享那个秘密(KDC在第一步为它们创建的Session Key)， KDC用Client与它之间的密钥将Session Key加密随加密的Ticket一起返回给Client。3 为了完成Ticket的传递，Client将刚才收到的Ticket转发到Service. 由于Client不知道KDC与Service之间的密钥，所以它无法算改Ticket中的信息。同时Client将收到的Session Key解密出来，然后将自己的用户名，用户地址（IP）打包成Authenticator用Session Key加密也发送给Service。4 Service 收到Ticket后利用它与KDC之间的密钥将Ticket中的信息解密出来，从而获得Session Key和用户名，用户地址（IP），服务名，有效期。然后再用Session Key将Authenticator解密从而获得用户名，用户地址（IP）将其与之前Ticket中解密出来的用户名，用户地址（IP）做比较从而验证Client的身份。5 如果Service有返回结果，将其返回给Client。概括起来说Kerberos协议主要做了两件事1 Ticket的安全传递。2 Session Key的安全发布。再加上时间戳的使用就很大程度上的保证了用户鉴别的安全性。并且利用Session Key，在通过鉴别之后Client和Service之间传递的消息也可以获得Confidentiality(机密性), Integrity(完整性)的保证。不过由于没有使用非对称密钥自然也就无法具有抗否认性，这也限制了它的应用。不过相对而言它比X.509 PKI的身份鉴别方式实施起来要简单多了。术语Realm: 一个Kerberos的认证数据库所负责的一个网络范围称作一个Realm。这个数据库中存放有该网络范围内的所有Principal和它们的密钥，数据库的内容被Kerberos的认证服务器AS和TGS所使用。Realm通常用大写的字符串表示,并且在大多数Kerberos系统的配置中，Realm的范围和该网络环境的DNS域是一致的。Principal: 在Kerberos中，Principal是参加认证的基本实体。一般来说，它有两种，一种用来代表网络服务使用者的身份，另一种用来代表某一特定主机上的某种网络服务，也就是说Principal是用来表示客户端和服务端身份的实体。为了使用方便，用户所见到的Principal是用一个字符串来表示的(而在网络传输中, Principal的格式采用ASN.1标准,即Abstract Syntax Notation One，来准确定义)，用户所见的这个字符串共分为三个部分：Primary: 第一部分。在代表客户方的情况，它是一个用户名； 在代表服务方的情况，它是一种服务的名字。Instance: 第二部分。对Primary的进一步描述，例如Primary 所在的主机名或Primary的类型等,可省略。它与第一部分之间 用/分隔。Realm: 第三部分。Principal所在的Realm。与第二部分之间用 分隔，缺省为本地的Realm。Credential: Ticket和与它相联系的会话密钥合在一起称为Credential。在下文中可以见到，之所以有这个概念是因为它们是客户端在向服务器证明自己的身份时必需的两样东西在一个Ticket的生存期内客户端会将这两样东西以Credential为单位保存在一个Cache文件中。Ticket: 一个Ticket是一个用于安全的传递用户身份所需要的信息的集合。它不仅包含该用户的身份，而且包含其它一些相关的信息。一般来说，它主要包括客户方Principal，目的服务方Principal，客户方IP地址，时间戳（分发该Ticket的时间），该Ticket的生存期，以及会话密钥等内容。它的格式亦用ASN.1来准确定义。Authenticator: 在客户端向服务端进行认证时，伴随Ticket一起发送的另外一个部分，它的作用是证明发送Ticket 的用户就是拥有Ticket的用户，即防止重放攻击。它的主要内容是一个时间戳（客户端发送Ticket的时间），在rfc1510中有它的完整的ASN.1定义。AS(Authentication Server): 为用户分发TGT(Ticket Granting Ticket)的服务器。TGT(Ticket Granting Ticket): 用户向TGS(Ticket Granting Server)证明自己身份的Ticket.TGS(Ticket Granting Server): 为用户分发到最终目的Ticket的服务器，用户使用这个Ticket向自己要求提供服务的服务器证明自己的身份。AS,TGT,TGS这三个概念在这里只能给出简单的叙述，它们确切的含义在下面的“协议描述”一节自然可以见到。在实现上，AS和TGS实际上是由同一程序完成的，因为它们的实现机制并没有太大的差别，只是在加密所发出的Ticket时所使用的密钥不同（AS使用用户的密钥，而TGS使用会话密钥）。KDC(Key Distribution Center): 这个概念是历史遗留下来的，比较模糊通常将AS和TGS统称为KDC，有时也把AS 单独称为KDC。Kerberos V4Kerberos的记号C：客户端 ； S：服务器；ADc：客户的网络地址； Lifetime：票据的生存期；TS：时间戳； Kx：x的秘密密钥；Kx,y：x与y的会话密钥； Kxm：以x的秘密密钥加密的m； Ticketx：x的票据； Authenticatorx：x的鉴别码Kerberos V4认证过程第一阶段，认证服务器的交互，用于获取票据许可票据：(1) C AS ：IDCIDtgsTS1(2) AS C ：EKc KC,tgsIDtgsTS2LT2Tickettgs 其中：Tickettgs = EKtgs KC,tgsIDCADCIDtgsTS2LT2第二阶段，票据许可服务器的交互，用于获取服务许可票据： (3) C TGS ：IDSTickettgsAUC(4) TGS C ：EKc,tgs KC,SIDSTS4TicketS 其中：Tickettgs = EKtgs KC,tgsIDCADCIDtgsTS2LT2TicketS = EKS KC,SIDCADCIDSTS4LT4AUC = EKc,tgs IDCADCTS3第三阶段，客户与应用服务器的交互，用于获得服务：(5) C S ：TicketSAUC(6) S C ：EKc,S TS5 + 1其中： TicketS = EKS KC,SIDCADCIDSTS4LT4 AUC = EKc,S IDCADCTS5Kerberos V5 身份验证Kerberos V5 协议可验证请求身份验证的用户标识以及提供请求的身份验证的服务器。这种双重验证也称为相互身份验证。Kerberos V5工作原理Kerberos V5 身份验证机制颁发用于访问网络服务的票证。这些票证包含能够向请求的服务确认用户身份的经过加密的数据，其中包括加密的密码。除了输入密码或智能卡凭据，整个身份验证过程对用户都是不可见的。Kerberos V5 中的一项重要服务是密钥分发中心 (KDC)。KDC 作为 Active Directory 目录服务的一部分在每个域控制器上运行，它存储了所有客户端密码和其他帐户信息。Kerberos V5 身份验证过程按如下方式工作：客户端系统上的用户使用密码或智能卡向 KDC （AS）进行身份验证。KDC 向此客户端颁发一个特别的授权票证（TGT）。客户端系统使用该 TGT 访问授票服务 (TGS)，这是域控制器上的 Kerberos V5 身份验证机制的一部分。TGS 接着向客户端颁发服务票证（ticket）。客户端向所请求的网络服务出示服务票证（ticket）。服务票证向此服务证明用户的身份，同时也向该用户证明服务的身份。Kerberos V5 服务安装在每个域控制器上，并且 Kerberos 客户端则安装在每个工作站和服务器上。每个域控制器作为 KDC 使用。客户端使用域名服务 (DNS) 定位最近的可用域控制器。域控制器在用户登录会话中作为该用户的首选 KDC 运行。如果首选 KDC 不可用，系统将定位备用的 KDC 来提供身份验证。Kerberos V5认证协议主要由5步构成:第一步：Client向AS申请TGT。解释：Client向AS发送的消息主要有：代表自己的Principal ”c”, 代表所申请服务的Principal ”tgs”,以及一个随机串 “n”，n的作用在下面可以见到。第二步：AS发送TGT和会话密钥 给Client。解释：AS收到Client第一步发来的消息后，由Principal “tgs”知道Client是要申请TGT。在验证数据库中存在Principal “c”后，它首先产生能够证明Client身份的Ticket 和一个随机的会话密钥 。然后它发给Client下列消息：用c的密钥加密的 和n，以及用TGS的密钥 加密的 。将Client发送过来的n加密后发回的作用是向client证明自己就是AS，从而防止第三方的欺骗.因为 只有Client和AS两者知道，故 ,n 只能由AS发出。第三步：Client向TGS申请访问Server的Ticket。解释：Client在收到第二步AS发回的消息后，首先用自己的密钥 解密 ,n ，得到 和n，然后将这个n与第一步发出的n相比较，如不同则说明有错。如相同，则把 和 保存在Credential的Cache文件中. 接下来，Client产生Authenticator ，并把它用 加密。最后Client向TGS发送消息，消息的内容有：照搬第二步收到的 ，用 加密的 ，代表要申请的服务的Principal “s”,还有一个新的随机串n（作用同第一步中的n）。第四步: TGS 发送 和会话密钥 给Client。解释：TGS收到Client第三步发来的消息后，首先用自己的密钥 （只有TGS和AS知道 ）解密 得到 ，进一步可以从 中得到 ，然后便可以解密出 。接下来，它将 中的c和realm与 中的c和realm相比较，看它们是否一致。如果不一致，说明有错。如果一致，说明 是用 加密的。如果 中的时间戳不是最近的（例如5分钟以内，由系统配置），说明有可能是重放攻击。如果 中的三元组(c,s,timestamp)是最近见到过的,也说明有可能是重放攻击。如果不是最近见到过的，TGS会把这个三元组记录下来，作为以后比较用。除此之外，TGS还会检查 是否超过了它的生存期。如果这些检查都获得通过，TGS便相信Client知道 ，又因为 在客户端上只能用 解密得到，也即Client知道 ，那么Client的身份就是c。 在确认Client的身份后，TGS便产生随机的会话密钥 和票据 .然后它从数据库中取出s的密钥 ，进行一番加密过程之后，把 ,n 和 发送给Client。第五步：Client将 提交给Server。解释：Client收到TGS第四步送到的消息后的处理与第三步中的描述基本相同，只不过是将解密的密钥由 换成了 ，加密的密钥由 换成了 。 最后，它把 和 发给Server。Server辨别Client身份的方法与TGS辨别Client身份的方法相同，请参见第四步描述。如果Client反过来需要Server向它证明身份，那么Server便会将 中的timestamp用 加密并返回给Client，以证明自己就是Server。在以后的通讯中，双方就可以用 或用 协商的新的子会话密钥来加密通讯数据（用以保证数据的保密性），也可以用它们来计算通讯数据的校验和（用以保证数据的完整性）。 这里特别需要指出的是，Kerberos协议中要求用户经过AS和TGS两重认证的好处主要有两个：一是可以显著减少用户密钥的密文的暴露次数，因为这样就可以减少攻击者对有关用户密钥的密文的积累；二是使Kerberos认证过程具有“Single Sign-on”（即一次性认证）的优点，通过上面的介绍可以看到，只要用户拿到了TGT并且该TGT没有过期，那么用户就可以使用该TGT通过TGS完成到任一个服务器的认证而不必重新输入密码。Kerberos V5的不足1 不能很好的防止口令猜测攻击 为了使用的方便,用户的密钥都是由一个password按某种算法转化而成的。由于在网上传输的是 ,n ，其中的n是可以旁听到的，这样就给猜测 提供了可能。其实，大括号中的东西不止 和n，还有其它一些具有可读性的明文，这样猜测 就变得更为容易。由于同样的原因，猜测会话密钥也是可能的。 Kerberos V5的设计者也意识到了这一问题，在Kerberos V5中作了以下几点努力： Ticket具有生存期，在生存期内使用者不必再次申请Ticket，这样就大量减 少了攻击者可以积累的被用户密钥加密的密文。其次，这一点也是出于使用起来方便的考虑。 由于Ticket和会话密钥会被保存起来，以便以后再次使用，这样就使会话密钥被猜中的可能性增大。为了弥补这一不足，在每一次新的连接中，客户端和服务端可以商定一个新的子会话密钥，当连接关闭时，这个子会话密钥就会消失。 在请求Ticket的时候，可以设置pre-authentication选项。这个选项可以用来指明认证需要使用另外一种手持设备，这种手持设备能够在 的基础上产生不断变化的密钥。这样，就可以几乎完全阻止猜测口令攻击，但缺点是需要使用额外的设备。2 用时间戳来阻止重放攻击代价偏高为了使用时间戳来阻止重放攻击，服务器程序必须做以下这些工作： 比较实际获得的客户端IP地址和Ticket中含有的客户端IP地址，看它们是否一致。 保存所有有效的三元组（c，s，timestamp）。 每收到一个最近的（fresh）时间戳，都要把它和保存的所有三元组进行比较如果发现有相同的，则说明是重放攻击同时删除那些过期的三元组。 由于可能有很多的服务进程同时运行，以上关于三元组的操作必须用某种机制来保持互斥。由此可见，如果这种服务比较繁忙的话，那么它运行的速度将会有明显的降低。实际上，在Kerberos V4中就已经提出了这种解决方法，但是一直拖到Kerberos V5才给予实现，MIT对此的解释正是这种解决方法的代价比较高。3 时间同步问题是一个薄弱环节从以上的描述中可以看到，Kerberos V5在很多地方都要用到时间，比如Ticket具有生存期，Authenticator中含有时间戳等等。如果分布在各地的主机的时间很难保持一致，那么Kerberos认证系统就很难正常的运行。虽然Kerberos系统允许各个主机的时间有一定的偏差（最大偏差由系统管理员来定义），并在程序设计中把这个偏差考虑了进去，但是由于各台主机的时钟并不能很好的保持走时准确，这个偏差会越来越大。如果各主机的物理时钟实在差别比较大，则有必要采用某种时间同步协议，然而