• Kerberos的原理 2


     

    第二幕


    Euripides 的办公室,第二天早上。Euripides 坐在他的桌子旁边,读着他的邮件。Athena 来敲门.


    Athena: 我已经想出怎样保护一个开放的网络系统,使象你那样不道德的人不能用别人的名字使用网络服务。
    Euripides: 真的吗?坐吧。
    她坐下了。
    Athena: 在我开始描述之前,我可以为我们的讨论先做一个约定吗?
    Euripides: 什么约定?
    Athena: 好,假设我这样说:"我想要我的邮件,于是我与邮件服务器联系,请求它把邮件送到我的工作站上来。"实际上我并没有联系服务器。我用一个程序来与服务器联系并取得我的邮件,这个程序就是这个服务的客户端代理。 但我不想每次与服务器交互的时侯说:"客户端怎样怎样".我只想说:"我怎样怎样,"记住,客户端代理在代表我做所有的事。这样可以吗?
    Euripides: 当然。没问题.
    Athena: 好。那么我要开始阐述我所解决的问题了。在一个开放的网络环境中,提供服务的机器必须能够识别请求服务的实体的身份。如果我去邮件服务器申请我的邮件,服务程序必须能够验证我就是我所申明的那个人。
    Euripides: 没错.
    Athena: 你可以用一个笨办法解决这个问题:服务器让你输入你的口令。通过输口令的办法我可以证明我是谁。
    Euripides: 那确实很笨拙。在像那样的系统里面,每一个服务器必须知道你的口令。如果网络有一千个用户,那每个服务器就要知道一千个口令。如果你想改变口令,你就必须联系所有服务器,通知它们修改口令。我想你的系统不会那么笨。
    Athena: 我的系统没那么笨。它是象这样工作的:不光人有口令,服务也有口令。每个用户知道他们自已的口令,每个服务也知道它自已的口令。有一个认证服务知道所有的口令,用户的和服务的。认证服务把口令保存在一个单独的中央数据库中。
    Euripides: 这个认证服务有一个名字吗?
    Athena: 我还没想好。你想一个吧?
    Euripides: 把死人送过冥河的人是谁?
    Athena: Charon ?
    Euripides: 对,就是他。如果他不能证实你的身份的话,他就不会把你送过河。
    Athena: 你瞎编,你是不是想重写希腊神话。Charon 不关心你的身份,他只是确定你死了没有。
    Euripides: 你有更好的名字吗?


    停了一下。

    Athena: 没有,真的没有。
    Euripides: 好,那我们就把这个认证服务 "Charon”。
    Athena: 好,我猜我该描述一下这个系统了吧,嗯?
    比如说我们想要一种服务:邮件。

    在我的系统里面你无法使用一种服务,除非 Charon 告诉服务你确实是你所申明的人。也就是说你必须得到 Charon 的认证才能使用服务。

    当你向 Charon 请求认证的时候,你必须告诉 Charon 你要使用哪一个服务。如果你想用邮件,你要告诉 Charon。

     Charon 请你证明你的身份。于是你送给它你的密码。 Charon 把你的密码和它数据库中的密码相比较。如果相等,Charon就认为你通过了验证。

     Charon 现在就要让邮件服务知道你通过了验证。既然 Charon 知道所有服务的密码,它也知道邮件服务的密码。Charon 把邮件服务的密码给你,你就可以使用这个密码使邮件服务相信你已通过验证。

     问题是,Charon 不能直接给你密码,因为你会知道它。下次你想要邮件服务的时候,你就会绕过 Charon 使用邮件服务而不需要认证。你也可以假装某人来使用邮件服务。

    所以不是直接给你邮件服务的密码, Charon 给你一张邮件服务的“票”。这张票含有你的名字,并且名字是用邮件服务的密码加密的拿到票,你就可以向邮件服务请求你的邮件。你向邮件服务提出请求,并用你的票来证明你的身份。

    服务用它自已的密码来把票解密,如果票能被正确的解密,服务器将票里的用户名取出。服务把这个名字和随票一起送上的用户名进行比较。如果相符,服务器就认为你通过了验证,就把你的邮件发给你。
    你认为怎么样?
    Euripides: 我有些问题。
    Athena: 我猜到了。请讲。
    Euripides: 当服务解密一张票的时候,它如何知道它是被正确的解密的?
    Athena: 我不知道。
    Euripides: 也许你应该在票里包含有服务的名字。这样当服务解密票的时候,它就可以通过能否在票中找到自已的名字来判断解密是否正确。
    Athena: 很好。那票就应该是这个样子:
    (她把下面的东西写在了一张纸上)
    票-{用户名:服务名}
    Euripides: 那票就只包含用户名和服务名?
    Athena: 用服务的口令加密。
    Euripides: 我不认为这些信息就可以让票安全。
    Athena: 什么意思?
    Euripides: 假设你向 Charon 请求一张邮件服务的票。 Charon 准备了一张有你名字“tina” 的票。假设在当票从 Charon 传给你的过程中我拷了一份。假设我让我的工作站相信我的用户名是”tina“。邮件客户程序认为我就是你。用你的名字邮件客户程序用偷来的票向邮件服务器提出请求。邮件服务器把票解密,认为它是合法的。票里的用户名和发送该票的用户名是匹配的。邮件服务器就会发给 我你的邮件。
    Athena: 喔!那可不太好。
    Euripides: 但是我想到了一个办法来解决这个问题。或者说部分解决。我想 Charon 应该在票中包含更多的信息。除了用户名,票还应包含请求票的用户的IP地址。这将给你增加一层安全性。 我来演示。假设现在我偷了你的票。这票有你工作站的IP地址,并且这地址配不上我的
    工作站的地址。用你的名字我把偷来的票送给邮件服务器。服务程序把用户名和网络地址从票中解出,并试图匹配用户名和网络地址。用户名匹配可网络地址不匹配。服务器拒绝了这张票,因为它明显是偷来的。
    Athena: 英雄,英雄!我怎么会没想到。
    Euripides: 好了,这就是我要表述的。
    Athena: 那么票应该是这个样子的。
    她把下面的东西写在了黑板上。
    票-{用户名:地址:服务名}
    Athena: 现在我真的很激动。让我们来建一个Charon 系统看看它是否工作!
    Euripides: 没那么快。对于你的系统我还有些问题。
    Athena: 好吧。(Athena 从她的椅子上探出了身子)快说。
    Euripides: 听起来好像每次我想要得到服务我都要去取一张新票。如果我整天的工作,我可能不只一次的要取我的邮件。我每次取邮件都要去取一张新票吗?如果真是这样,我不喜欢你的系统。
    Athena: 啊。。。我不明白为什么票不能被重用。如果我已经得到了一张邮件服务的票,我可以一次又一次使用它。当邮件客户程序用你的名字请求了服务,它就传了一份票的拷贝给服务。
    Euripides: 好一些。但我仍有问题。你似乎暗示我每次使用还没有票的服务时,我都必须给 Charon 我的密码我登录后想取我的文件。我向 Charon 请求我的票,这意味着我不得不使用我的密码。然后我想读我的邮件。又向 Charon 发一次请求,我又要输一次我的密码。现在假设我想把我的邮件送去打印。我又要向 Charon 发一次请求。你知道了吧?
    Athena: 啊,是的,我明白了。
    Euripides: 并且如果这还不够糟的话,想想看:它好像是这样,当每次你要向 Charon 认证的时候,你就要用明文在网络上传输你的口令。像你这样的聪明人可以监视网络并且得到别人的口令。如果我得到你的口令,我就可以用你的名字来使用任何服务。
    Athena叹了口气。
    Athena: 确实有严重的问题。我想我该回设计室去了。


  • 相关阅读:
    openstack私有云布署实践【7.2 keystone + memcache (办公网环境)】
    openstack私有云布署实践【2 安装前的服务器基本环境准备】
    openstack私有云布署实践【11.1 计算nova compute节点配置(科兴环境)】
    openstack私有云布署实践【4.2 上层代理haproxy+nginx配置 (办公网测试环境)】
    openstack私有云布署实践【9.1 Glance镜像管理(科兴环境)】
    openstack私有云布署实践【7.1 keystone + memcache (科兴环境)】
    openstack私有云布署实践【10.1 计算nova kxcontroller节点配置(科兴环境)】
    openstack私有云布署实践【6 RabbitMQ】
    openstack私有云布署实践【4.1 上层代理haproxy配置 (科兴环境)】
    openstack私有云布署实践【8.2 身份认证keystone的API创建(办公网环境)】
  • 原文地址:https://www.cnblogs.com/haogj/p/1841712.html
Copyright © 2020-2023  润新知