Kerberos原理--经典对话

前言

  最近在学习Kerberos原理,无意间发现了Kerberos原理 – 经典对话,好家伙全是英文,果断网上寻找中文版。但网上的翻译水平实在不敢恭维,很多都是机翻,读都读不通,这个我觉得还好。让我要命的是,连最基本的排版都没有,文字全部挤在一堆,严重影响阅读体验。当时我就花费了5天完成了翻译与排版。因本人知识水平有限,难免会出现词不达意。在此恳求大家的帮助,一起优化与改进翻译。转载请保留原地址,谢谢!最后祝君阅读愉快!


Designing an Authentication System:
a Dialogue in Four Scenes

  版权所有1988,1997麻省理工学院。版权所有

  原作者Bill Bryant,1988年2月。

  由Theodore Ts’o转换为HTML格式,1997年2月。在后记中添加了Kerberos V5的改动。

摘要

  这段对话将不断完善和优化一个叫”Charon”的网络系统。随着对话的推进,人物雅典娜和欧里庇得斯将一步步发现这个系统存在的安全问题。当每个安全问题出现时,他们将采取不同的应对方案。在对话的最后,他们成功创建出了一个安全可靠的系统。

  最终,雅典娜将此系统命名成”Kerbeors“,巧合的是,麻省理工学院的Athena项目设计的认证系统也是这个名称。1988年冬季在德克萨斯州达拉斯举行的 USENIX 大会上提出的Kerberos:一个网络认证系统,与此对话中的”Kerberos”系统有着惊人的相似之处。

目录

  ● 人物简介
  ● 第一幕
  ● 第二幕
  ● 第三幕
  ● 第四幕

人物简介

  雅典娜    前途无量的系统开发工程师

  欧里庇得斯  经验丰富的工程师

  为了减少工作量,在后面翻译中,将雅典娜和欧里庇得斯简写为:雅姐和欧里。这句话是译者所加。

第一幕

  在一个小工作室里,他们正在相邻的终端上工作。
  雅姐:哎,这个分时操作系统真的慢,每个人都来登录,我根本无法工作。
  欧里:别对我抱怨呀,我也是个打工人。
  雅姐:我觉得当务之急是给每人配一台电脑,这样就不必担心速度问题,然后再将所有计算机连接起来,形成一个网络。
  欧里:那样的话,大约要一千台电脑?
  雅姐:差不多。
  欧里:你不知道普通硬盘有多大吧,根本放不下所有的软件。
  雅姐:我当然知道,我们可以把软件放到服务器上。当登录到电脑的时候,电脑通过网络就可以使用服务器上的任意软件。如果要更新软件,你不必改动每台电脑里的软件,只需改动服务器上的软件。
  欧里:个人文件怎么办?以前我可以登录进分时系统上看我的文件,现在呢?
  雅姐:用其他电脑来存,要用的时候,登录到任意一台电脑去取你的文件。
  欧里:打印服务呢?未必每台电脑配台打印机啊?谁给钱?电子邮件呢?那邮件又怎么发给电脑?
  雅姐:啊这!每人一台打印机不现实,但可以专门有一台打印机。你可以向打印机发送打印任务,它就为你打印。邮件问题,按部就班,你想要邮件,可以连接邮件服务器去取走邮件,这样问题不就迎刃而解了吗。
  欧里:听起来不错。如果是我的话,我会用你的用户名,去收发邮件和改动你的私人文件,然后 嘿嘿。
  雅姐:你行吗?
  欧里:轻而易举好吧,问题在于,如何让服务器知道我不是你?
  雅姐:让我回去好好想想。
  欧里:行,等你好消息。

第二幕

  欧里的办公室,第二天早上,欧里坐在他的桌旁,读着邮件。此时传来,咚咚咚(敲门声),雅姐来了。
  雅姐:我已经想出办法了。
  欧里:坐下说。
     雅姐坐下
  雅姐:在我说之前,我们先制定一个约定,如何?
  欧里:什么约定?
  雅姐:如果我想收发邮件,我就必须连接邮件服务器。我的想法是,我不直接连接它。我专门用一个程序去连接,来收发邮件。我下达什么命令,程序就执行什么命令。此程序就代表我做事情,这样可以不?
  欧里:没问题。
  雅姐:我重新阐述一遍现在的问题,在一个开放的网络中,服务器必须能验证服务对象的身份,即如果我登录邮件服务器,它必须知道是我,而不是你。
  欧里:没错。
  雅姐:简单的办法,就是登录服务器时,必须输密码。这样就能证明谁是谁了。
  欧里:确实简单,但在那样的系统,每台服务器都必须存你的密码。假设有一千个用户,每台服务器就要存一千个密码。如果你要改密码,每台服务器对应的密码也要改。我希望这不是你的最终解决方案。
  雅姐:当然不是,听我说,用户和服务器都有属于自己的密码。当然,它们也知道自己的密码。有一个认证服务器知道所有的密码,它把密码单独放在中央数据库中。
  欧里:这个认证服务器有名字吗?
  雅姐:没想好,你想一个吧。
  欧里:冥河摆渡人叫啥来着?
  雅姐:Charon(卡戎)?
  欧里:是他,除非你能证明你的身份,不然他不会带你过河。
  雅姐:别扯淡了,你不会想改写希腊神话吧。Charon才不关心你的身份,他只在乎你死透没。
  欧里:你有更好的名字吗?
     雅姐陷入了沉思,几分钟后
  雅姐:没有,真的没有。
  欧里:认证服务器就叫”Charon”吧。
  雅姐:是时候描述这个系统了。

     比如我要用邮件服务,那么在我的系统里面,只有你通过了Charon的认证才能使用服务。而且在认证之前,你必须告诉Charon你要使用哪一个服务。比如邮件服务,你就必须告诉它,我要使用邮件服务。

     Charon让你提供密码以此来证明身份,它把你提供的密码和数据库中的密码相比较。如果相等,通过认证。

     之后Charon可以告诉你邮件服务的密码,你就可以使用此密码让邮件服务相信你通过了认证。

     问题在于,Charon不能直接给你密码。下次你就会直接使用此密码,来使用邮件服务,从而绕过了Charon的认证。当然你还可以假装某人使用邮件服务。

     基于以上考虑,Charon取而代之的是给你一张邮件服务的”票”,此票包含了你的用户名,并且已被邮件服务的密码加密。

     拿到票后,你把此票给邮件服务,以此来证明你的身份。

     邮件服务用自己的密码解密,如果能成功解出,它会得到你的用户名。

     它把此用户名和用票人用户名相比较。如果相等,验证通过,你可以收发邮件了。

     你觉得怎么样?

  欧里:我有一些疑问。
  雅姐:我就知道,说吧。
  欧里:邮件服务在解密时,如何判断票是否成功解密?
  雅姐:我不知道。
  欧里:你应该在票里包含有服务的名字。当成功解密的时候,它就可以通过能否在票中找到自已的名字,来判断解密是否正确。
  雅姐:太棒了,票应该是这个样子吧。

     (她在纸上潦草的写下以下内容)

     票 - {用户名:服务名}
     TICKET - {username:servicename}

  欧里:票就只包含用户名和服务名?
  雅姐:是的,并且还被服务的密码加密。
  欧里:我不觉得这样,就能让票足够安全。
  雅姐:什么意思?
  欧里:让我们假设一下,你向Charon请求一张邮件服务的票。Charon准备了一张写上你的名字”雅姐”的票。如果票从Charon传给你的过程中我拷贝了一份。然后我又假装我的名字是”雅姐”,我再把偷来的票发给邮件服务器,它解密后,票里的用户名和用票人用户名相匹配。我就可以得到你的邮件了。
  雅姐:这……
  欧里:我有一个办法也许能解决此问题,Charon应该在票中包含更多的信息,比如用户的IP地址,这样就更加安全了。

     假设现在我偷了你的票,票中包含了你的IP地址。我假装是你,再把偷来的票给邮件服务器,它解密后,只能匹配上用户名,匹配不上IP地址。验证失败,因为明显是偷来的。

  雅姐:nb,nb!我怎么就没想到。
  欧里:哈哈,这就是我要表达的意思。
  雅姐:那票就应该这样。

     她在黑板上潦草地写着

      票 - {用户名:IP地址:服务名}
      TICKET - {username:ws_address:servicename}

  雅姐:我迫不及待的想看Charon系统是怎么工作。
  欧里:别慌,这个系统还有一些问题。
  雅姐:(雅姐向前探了探身子) 别买关子了,快说说。
  欧里:我每次使用邮件服务,就要取一次票,要是取票次数多了,真的烦。这样的话,说实话,你的系统真不咋地。
  雅姐:你可以重复使用邮件服务的票。比如,当你使用邮件客户程序时,就已经拷贝了一张票给邮件服务器。
  欧里:还有一个问题,我每次使用还没有得到票的服务前,都必须给Charon我的密码。比如我使用邮件服务,就要输入一次。使用文件服务,又要输入一次。打印服务,还要输入一次。这就是缺陷,懂我意思吧。
  雅姐:懂。
  欧里:更糟糕的事也许是这个,想想看,每次向Charon认证的时候,就会在网络中明文传输你的密码。不法分子就可以监听网络流量获取密码。如果我得到了你的密码,我就可以使用你的名字来使用任何服务。雅姐叹了口气。
  雅姐:确实是个严重的问题,搞不好要重新设计系统了。

第三幕

  第二天早上,雅姐在咖啡店遇见了欧里。在他倒咖啡的时候,她拍了拍他的肩膀。

  他们走向咖啡机

  雅姐:我想出了一个新的Charon版本来解决我们的问题。
  欧里:我去,这么快
  雅姐:为了解决问题,昨晚我彻夜未眠。
  欧里:去那边的会议室谈吧。
  雅姐:走。

     他们进了会议室

  雅姐:下面我会说明如何解决问题。

     雅姐清了清嗓子

  雅姐:第一条:用户只需输一次密码,意味着每当需要使用新的服务时,不必再输入密码。第二条:密码不能明文传输。
  欧里:好的
  雅姐:我进一步解释第一条:用户只需输入一次密码。我创造了一个新的服务,叫做”票据授权”服务(TGS)。它会取代Charon的发票功能。如果你有它发放的服务票证,可以使用此票对应的服务。

     票据授权服务也是Charon的一部分,理所当然它也能读取数据库。

     现在,认证系统应该是这样工作的:你使用一个叫kinit的程序去连接Charon,如果通过了Charon的验证,kinit将会得到了一张票据授权票(TGT)。

     现在你想使用邮件服务,然而还没有邮件服务的票,所以你使用”票据授权”票去取邮件服务的票。至此你将不再使用密码去申请一张新票了。

  欧里:那我每次使用其他服务的时候,我还要去取一张”票据授权”票吗?
  雅姐:不用,上次你我已经同意能重复使用票。只要你有”票据授权”票,可以使用此票获取你需要的其他服务票。
  欧里:哇,棒啊,再也不用重复申请票了。
  雅姐:不妙吗?
  欧里:妙啊!真是妙蛙种子吃着妙脆角妙进了米奇妙妙屋,妙到家了。那密码明文传输呢?
  雅姐:也很简单,当你连接Charon去申请一张票据授权票时,感觉上是密码明文传输,实际上不是这样的。

     你用kinit程序取得票据授权票时,不再发送密码,而只发送你的用户名。

  欧里:可以。
  雅姐:Charon用此用户名查你的密码,之后Charon会制作一个包含票据授权票(TGT)的数据包,并且用你的密码加密此数据包。

     然后你的电脑接收到此数据包,你输入你的密码,Kinit用你输的密码进行解密。如果解密成功,说明你已通过Charon验证,就能获得票据授权票,就能用此票去取其他服务票。

     这奇思妙想怎么样?

  欧里:让我仔细思考一下,就你刚刚说所的,只需要我认证一次,挺不错的。之后Charon会不知不觉的给我服务票,简直天衣无缝啊。其实有个问题,重用的票,因其本身的设计缺陷。会导致安全问题。
  雅姐:什么意思?
  欧里:假设这么一个场景,你获得了邮件服务票,打印服务票和文件服务票。但当你注销时,却无意留下了这些票。

     现在我用你的名字登录上去并且找到了这些票,既然那些票上是你的名字,我就可以随意的取你的邮件,动你的文件。归根结底,是你的疏忽而造成的。

     甚至我还可以把这些票拷走,永远的使用它们。

  雅姐:也很好解决,我们可以写一个程序,当用户登录时销毁票,这些票再也不能被用。
  欧里:那么你的系统又需要一个票据销毁程序,你指望用户每次关机前使用票据销毁程序,既不现实,又愚蠢。即使能实现,请考虑以下情况:

     我有一个能监听网络并且能偷票的程序,假设你是我的目标。我等你上线后,立即把票偷过来。

     等你注销并离开后,我把我的IP改成你的,这样电脑就会以为我是你,我有你的票,用户名,IP地址,我就能利用这些票并以你的身份使用服务。

     到那时,你销毁票也已经无济于事了。这些偷来的票我能随时随地的用。因为你的这些票并没有限制使用次数,和限制使用时间。

  雅姐:我懂你意思了,票不能永远合法,这样有安全问题。也许可以给每张票设一个有效期。
  欧里:是的,我想票需要再加两个信息:票能使用多久和Charon发票时间,所以票就应该是这样:

     欧里走到黑板前写下以下内容:

     票 - {用户名:IP地址:服务名:有效期:时间戳}
     TICKET {username:address:servicename:lifespan:timestamp}

  欧里:现在当服务解密时,它会检查票的用户名和IP地址,是否与发送者匹配,然后再用有效期和时间戳检查票是否有效。
  雅姐:那票一般有效期是多久?
  欧里:差不多8小时吧。
  雅姐:那如果我用电脑超过8小时,所有的票就会失效,也包括票据授权票(TGT)。岂不是8小时后,Charon要重新验证我的身份。
  欧里:感觉有点不合理?
  雅姐:不会,就这样吧。我问你个问题,假设我偷了你的票。
  欧里:(眨了眨眼睛),不会吧,不会吧,不会你真的那样做吧。
  雅姐:额,我只是和你讨论。假设我偷了你的票,而你两小时后预约了医生或者有课,你离开前并销毁了你的票。

     所以票还有6小时的有效期,我有足够的时间拿这些票搞事情。

     即使时间戳加上了,只要在失效前使用…

  欧里:确实
  雅姐:我们遇上了大问题了。(她叹了口气)
       双方沉默了一会儿
  欧里:某人可能今晚又要失眠了,再喝点咖啡吧?
  雅姐:满上。

第四幕

  第二天一大早,雅姐就来敲欧里办公室的门。
  欧里:我去,你有黑眼圈了。
  雅姐:昨晚,又是一个漫漫长夜。
  欧里:想出办法了吗?
  雅姐:必须的
  欧里:请坐
     雅姐坐下
  雅姐:按照惯例,我再次回顾一下问题。票在8小时内可以重用,但如果某人偷了票,在失效前使用,我们束手无策。
  欧里:确实如此。
  雅姐:如果票不能重复使用,就能解决此问题。
  欧里:这不又和以前一样,用一次新服务取一次新票。
  雅姐:是的,虽然这个办法属实不咋滴。(停顿),怎么说呢?(她思考了一会)

     有了,再屡一遍问题,网络服务必须能够证明票上的人名就是用票者。

     让我顺着认证过程再走一遍,看能否想出解决办法。

     现在我用程序去访问一个服务,那么需发送三样东西给服务器,分别是:我的用户名,我的IP地址,服务票。

     此服务票包含我的用户名,我的IP地址,有效期,时间戳。而这些信息都被服务的密码加密。

     对此提出以下问题:

     ● 票能否被服务正确解密?
     ● 票是否在有效期?
      ● 票上的用户名和IP地址是否和用票者的匹配?

      上述问题能说明什么?第一个问题,如果票不能被解密,说明票不是Charon发放的。因为只有真正的Charon和服务知道服务的密码,Charon用服务的密码加密,服务用此解密。如果解密失败,说明有人伪造了票。

      第二个问题,如果票过期,理所当然是不能被服务接受的。说明使用了旧票或者有人偷票。

      第三个问题,如果不匹配,票肯定被偷了。

      再继续讨论第三个问题,如果匹配能说明什么?什么也不能说明,因为偷票的人可以改变用户名和IP地址。正如我昨天所说的,票可以在有效期内被盗用,因为服务不能确定发票者是不是本人。

      之所以服务无法确定,是因为没有和用户有个接头暗号。这样看,假如我正在Elsinore(埃尔西诺:一款角色扮演游戏),哈姆雷特中的城堡值勤。此时你要和我换班,那么你必须提供正确的暗号,不然我不会和你换班。而这个暗号是某人为所有值勤的人设定的。

      昨晚我就在想,为什么Charon不这样搞呢?它发一份会话密钥(session key)给服务,同时发一份给用户。当服务收到用户的票时,它可以用此会话密钥验证用户的合法性。

  欧里:等等,Charon怎么同时发两份密钥?
  雅姐:持票者从Charon的回应得到密钥,像这样子:

     她在黑板上潦草地写着

     Charon的回应 - [会话密钥 | 票]
     CHARON REPLY - [sessionkey|ticket]

     服务的密钥也会被包含在票中,所以当服务解密时就能得到密钥。票就像这样:

     票 - {会话密钥:用户名:IP地址:服务名:有效期:时间戳}
     TICKET - {sessionkey:username:address:servicename:lifespan:timestamp}

     
     当你请求一个服务时,客户端会生成一个”认证器”,它包含了你的用户名和IP地址。这些信息被会话密钥加密。

     认证器 - {用户名:IP地址} 被会话密钥加密
     AUTHENTICATOR - {username:address} encrypted with session key

     生成认证器后,客户端把它和票发送给服务,因为服务没有密钥,所以无法解开认证器。而票包含了密钥,理所当然服务先解开票。

     解开票后,服务会得到以下信息:

      ● 票的有效期和时间戳
     ● 票拥有者的用户名
      ● 票拥有者的IP地址
      ● 会话密钥

      服务先检查票是否过期,如果没有,接下来使用会话密钥解密认证器。如果成功解密,将得到用户名和IP地址。最后服务用票里的用户名和IP地址,与解密后的信息去匹配。匹配成功,服务确定用票者就是本人。

     雅姐停顿了一会,喝口咖啡,清了清嗓子。

     我认为这种验证机制解决了盗用问题。

  欧里:也许。但我想。。。攻击这个系统,我要有认证器。
  雅姐:别忘了你还得有票,没有票,认证器就变得一文不值。解开票后才能解开认证器。
  欧里:行,对了,客户端请求服务时,会把认证器和票同时发送给它?
  雅姐:对啊。
  欧里:这样的话,我可以写个程序,偷走票和认证器,和前面一样改个用户名和IP地址并在票失效前使用,不也一样的吗?
  雅姐:(咬了咬她的嘴唇),无语了。
  欧里:别沮丧,票能重用,又没说认证器能重用,把认证器设计成只能用一次就行了。
  雅姐:对啊,真票和认证器永远比你偷过来的先到服务端。如果认证器只能用一次,偷的那份就废了。

     现在要做的就是让认证器只能使用一次。

  欧里:是的,我们可以把有效期和时间戳放在上面。假设每个认证器最多2分钟的有效期。认证器再标上当前时间,把它和票一起发给服务。

     服务器收到了票和认证器,它解开认证器,检查认证器是否过期。如果没有,其他验证也通过的话,服务器认为你通过了验证。

     假设我从网络上偷了它们,还要在两分钟之内改变我的IP地址和用户名。基本不可能,除非。。。

     其实有个潜在问题,如果我不偷认证器和票了,我直接偷一份Charon给你的原始票证数据包。

     这个数据包有两个密钥在里面:一个是你的,一个是服务的。服务的密钥我拿不到,你的呢?

     如果我拿到了密钥,我就能自己构造认证器,再次攻破你的系统。

  雅姐:昨晚我想过这个问题,其实这是不可能发生的。

     假设你坐在电脑前,用kinit程序去申请票据授权票(TGT),然后你输入用户名,之后kinit把它发送给Charon。

     Charon用你的用户名查找你的密码,然后生成一张票据授权票。之后Charon生成一个你和服务共享的密钥。Charon将一份密钥放进票里,一份放在你即将收到的数据包里。别忘了,在发送此数据包之前,Charon会用你的密码加密这个数据包。

     即使在Charon发包的过程中,有人偷取到了,不知道你的密码也毫无作用,所以没人能窃取密钥。

     Kinit收到数据包,提示你输入密码,如果正确,解开数据包,你将获得密钥。

     下面是kinit的工作方式,你想使用邮件服务,Kinit便尝试查找邮件服务票,自然没有找到(因为你之前没有取过邮件)。客户端用票据授权票(TGT)去申请邮件服务票。

     客户端会生成一个认证器,里面的信息被你请求票据时的密钥所加密。然后客户端会将认证器,票据授权票,你的用户名,你的IP地址,邮件服务名发送给Charon。

     票据授权服务(TGS)收到这些东西后,如果通过了认证,票据授权服务将得到那个和你共享的会话密钥。现在票据授权服务将给你一张邮件服务票,在此过程中,生成一个新的会话密钥供你和邮件服务共享。

     票据授权服务把这些东西打包发给你的电脑,数据包包含了邮件服务票和会话密钥。注意在发包之前,数据包已被票据授权服务的密钥加密。

     假设数据包在网络传输中,被某人复制了。很不幸的是此数据包被加密的。而只有你和票据授权服务知道会话密钥。所以他无法解密数据包,也无法得到邮件服务密钥。我觉得这是个非常安全的系统,你觉得呢?

  欧里:也许吧。
  雅姐:也许!你就只会说这个!
  欧里:(大笑),别在意啊。你知道我的说话方式。我相信你昨天确实想了一宿。
  雅姐:哼!
  欧里:好吧,其实昨天我也想了大半夜,实际上这个系统,解决了我昨晚想的问题:身份相互验证的问题。

     稍顿

     介意我说几分钟吗?

  雅姐:(有点冷淡)请便。
  欧里:谢谢。(欧里清了清嗓子),昨晚,当会话密钥和认证器在你脑海中想象时,我试图寻找其中的漏洞。果不其然,我发现了一个非常严重的问题。我将通过下面的场景具体说明。

     假设你现在准备离职,于是使用打印机打印下次的求职信。

     你下达了打印命令,这个命令去取打印服务票,此票会回到打印服务器上。不出意外的话,这是正确的流程。实际上,你也不知道请求是不是发到了正确的打印机上。

     假设某个黑客——比如你的老板——改变了系统,把你的请求发送到他办公室的打印机。打印服务根本不关心票和票的内容,于是它告诉你的电脑,我已准备打印你的文件。这样你的求职信就会被你老板得到。

     我举这个例子,是想说明,如果没有会话密钥和认证器,Charon可以保护服务不受假冒用户的攻击,但不能保护用户不受假冒服务的攻击。所以在发这些敏感信息之前,系统必须要让客户端和服务器相互认证

     会话密钥完美的解决了此问题,让我们回到刚刚的场景。我想要打印程序确认,它向其发送作业的服务是否是合法的。

     使用打印服务时,假设我得到了打印服务票和密钥。客户端程序使用此密钥创建了一个认证器,之后将认证器和票发给”指定的”打印服务器。注意客户端此时还没发打印文件,它现在等待打印服务器的响应。

     真的服务收到票和认证器,解开票获得密钥,然后使用此密钥解开认证器。等它检查完所有的认证后,你就通过了它的验证了。

     现在打印服务器准备了一个响应包来证明自己的身份,它用会话密钥加密了响应包,并把包发送给等待中的客户端。

     客户端收到响应包后用密钥解密,如果成功,将会得到打印服务器正确的响应信息,客户端就知道这个打印服务器是合法的。此时客户端将文件发给打印服务。

     假设我的老板又像上次那样假冒打印服务,客户端将票和认证器发给它并等待响应,而假冒的打印服务是无法生成正确的响应的,因为它无法解开票并得到密钥。之后客户端没有得到正确的响应,放弃等待,退出打印服务。虽然打印失败了,但也比我老板得到我的求职信强。

     我想Charon认证系统已经坚不可摧了。

  雅姐:可能吧,但不管怎么样,我真心不觉得Charon这个名字好听。
  欧里:你什么时候又不喜欢了?
  雅姐:我就从来没喜欢过好吧,因为这个名字没含义,有次我和我的叔叔Hades(哈迪斯)讨论过这个,他说不如和守他家大门的三头狗一样的名字。
  欧里:你是说叫”Cerberus”(三头犬)。
  雅姐:你在说什么哦。
  欧里:难道不是这个名字吗?
  雅姐:是叫”Kerberos”,’K’开头的”Kerberos”。
  欧里:好好好,别发火,我同意这个名字。再见,Charon,欢迎,Kerberos。

后记

  这篇对话写于1988年,是为了帮助读者理解Kerberos V4工作原理,即使放到现在,也不过时。

  当我把这篇文章转成HTML的时候,我惊讶的发现这个文档对Kerberos V5仍然非常有用。虽然很多东西改变了,但核心内容是没有变的。实际上,Kerberos V5与对话中的”Kerberos”描述,只有两处改动。

  第一个改动是,发现即使认证器只有五分钟的有效期,在此时间段内,如果有人使用自动偷票和认证器程序,依然无法防止他们重用。

  在Kerberos V5中,认证器实现了真正的只能使用一次,这一功劳归功于”重用缓冲区”。它会将最近提交的认证器信息发送给服务器。如果攻击者试图偷取并重用认证器,”重用缓冲区”会发现认证器已经用过了。

  第二个改动是,Kerberos发给kinit服务票时,不再使用用户密码加密。票已经被票据授权服务的密钥加密。所以没必要再用用户密码加密一次。(而对Kerberos的其他响应,如密钥,它仍然是用用户的密码加密的)。

  票据授权服务(TGS)协议也发生了改动,票据授权票也不再被票据授权服务的密钥加密。因为它所包含的票已被对应服务的密钥加密。举例来说,Kerberos V4的包如下所示:

  KDC_REPLY = {TICKET, client, server, K_session}K_user

  其中{}中的内容被K_user加密,并且

  TICKET = {client, server, start_time, lifetime, K_session}K_server

  在Kerberos V5中,KDC_REPLY是这样的:

  KDC_REPLY = TICKET, {client, server, K_session}K_user

  当然,Kerberos V5还有许多新特征,用户可以在其他网络安全的使用票;或者,用户还可以将认证步骤转给服务器,这样服务器可以成为用户的代理。其他新特性,如用更安全的加密算法(如三重DES)代替DES算法。如果读者想知道V4与V5更多的变化细节,请移步Kerberos认证系统发展史,作者是Cliff Neumann Theodore Ts’o

  我希望读者能满意这篇对话,祝君在未来的探索中更上一层楼。

  Theodore Ts’o,1997年2月


Permission to use, copy, modify, and distribute this documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of M.I.T. not be used in advertising or publicity pertaining to distribution of the documentation without specific, written prior permission. M.I.T. makes no representations about the suitability of this documentation for any purpose. It is provided “as is” without express or implied warranty.

For comments/suggestions about this page, mail:tytso@mit.edu

查看评论 -
评论