Этот диалог написал Билл Брайант (Bill Bryant) в феврале 1988.
В феврале 1997 г. его отредактировал и преобразовал в HTML Теодор Цо (Theodore Ts'o). Он также добавил послесловие, описывающее изменения в Kerberos версии 5.
Вступление
В этом диалоге в художественной форме описано создание системы проверки подлинности для открытых сетей, названной "Харон". По мере развития обсуждения, главные герои Афина и Еврипид сталкиваются с проблемами безопасности, присущими окружению открытой сети. При создании Харона должны быть учтены все эти проблемы, в соответствии с этим и продвигается разработка. Афина и Еврипид не завершат свою работу, пока обсуждение не будет закончено.
Когда разработка системы была завершена, Афина переименовала её в "Kerberos", по странному стечению обстоятельств это имя совпало с именем системы проверки подлинности, разработанной в рамках проекта Афина, реализованном в MIT. Описанная в диалоге система Kerberos очень похожа на систему, описанную в материале Kerberos: Служба проверки подлинности для открытых сетевых систем, представленном на конференции Winter USENIX 1988, в Далласе, штат Техас.
Кубическая арена. Афина и Еврипид работают на соседних терминалах.
Афина:
Эй, Рип, это система с разделением времени просто тормоз. Я не могу ничего сделать, потому что в систему вошёл кто-то ещё.
Еврипид:
Не жалуйся мне. Я здесь всего лишь работаю.
Афина:
Ты знаешь, что нам нужно? Нам нужно дать всем отдельные рабочие станции, чтобы не задумываться больше о разделении компьютерного времени. И мы создадим сеть, соединив все рабочие станции, чтобы все люди могли связываться друг с другом.
Еврипид:
Прекрасно. И чего же нам не хватает, примерно тысячи рабочих станций?
Афина:
Что-то около того.
Еврипид:
А ты знаешь, какой размер имеет жёсткий диск обычной рабочей станции? На нём просто не хватит места для всех программ, работающих на компьютере с разделением времени.
Афина:
Это я уже выяснила. Мы можем хранить копии системного программного обеспечения на разных серверах. Когда ты зарегистрируешься на рабочей станции, этот компьютер обратится к системному программному обеспечению, соединившись с нужным сервером. Это позволит сразу многим рабочим станциям использовать одну копию программного обеспечения, и облегчит обновление программ. Тебе не нужно будет посещать каждую рабочую станцию. Обнови только сервера с программным обеспечением.
Еврипид:
Всё это хорошо. Но что ты собираешься делать с личными файлам? В системе с разделением времени я могу зарегистрироваться и обратиться к моим файлам с любого подключенного к ней терминала. Смогу ли я подойти к любой рабочей станции и автоматически получить к ним доступ? Или я должен уподобиться пользователю PC и носить свои файлы на диске? Надеюсь, нет.
Афина:
Я думаю, для хранения персональных файлов мы сможем выделить другие компьютеры. Ты сможешь зарегистрироваться на любой рабочей станции и добраться до своих файлов.
Еврипид:
А как быть с печатью? Для каждой рабочей станции потребуется свой принтер? Чьи деньги ты собираешься потратить? А как насчёт электронной почты? Ты собираешься рассылать почту по всем этим рабочим станциям?
Афина:
Э-э-э... Очевидно, у нас нет столько денег, чтобы купить каждому принтер, но мы можем выделить компьютеры для службы печати. Ты отправишь задание серверу печати, и он распечатает его для тебя. Ты может сделать что-то подобное с почтой. Выдели компьютер для почтовой службы. Тебе нужна твоя почта? Свяжись с почтовым сервером и забери её.
Еврипид:
Твоя система с рабочими станциями кажется достаточно хорошей. Знаешь, что я собираюсь сделать, когда получу свою станцию? Я выясню твоё имя пользователя и заставлю свой компьютер думать, что я - это ты. Затем я подключусь к почтовому серверу и прочитаю твою почту. Я также подключусь к твоему файловому серверу и удалю твои файлы, а потом...
Афина:
Неужели ты способен на это?
Еврипид:
Конечно! А как эти сетевые сервера узнают, что я – это не ты?
Афина:
Ну я не знаю. По-моему мне нужно немного подумать.
Следующее утро, офис Еврипида. Еврипид сидит за своим столом, читает свою почту. Афина стучит в дверь.
Афина:
Я придумала, как защитить открытое сетевое окружение, чтобы беспринципные люди вроде тебя не могли пользоваться сетевыми службами от имени других людей.
Еврипид:
Ну и как? Присядь.
Она садится.
Афина:
Прежде чем я опишу это, могу ли я выдвинуть базовое правило для нашего обсуждения?
Еврипид:
И в чём оно состоит?
Афина:
Предположим, я заявляю следующее: "Я хочу прочитать свою электронную почту, для этого я связываюсь с почтовым сервером и прошу переслать эту почту моему компьютеру". В действительности, с почтовым сервером связываюсь не я. Я использую программу, которая соединяется с почтовым сервером и получает мою почту, и эта программа является КЛИЕНТОМ почтовой службы.
Но я не хочу говорить "клиент делает это, клиент делает то" каждый раз, когда речь идёт о транзакции между пользователем и сетевым сервером. Я хочу просто говорить "я делаю это, я делаю то", не забывая о том, что вообще-то всё это делает клиентская программа. Ты с этим согласен?
Еврипид:
Конечно. Нет проблем.
Афина:
Хорошо. Ну что же, я начну с описания решённой мной проблемы. Компьютеры, предоставляющие службы в открытом сетевом окружении, должны иметь средства проверки подлинности людей, запрашивающих службы. Если я связываюсь с почтовым сервером и хочу получить свою почту, служба должна иметь возможность проверить, тот ли я, за кого себя выдаю. Так?
Еврипид:
Так.
Афина:
Мы можем решить эту проблему грубо, потребовав, чтобы почтовый сервер запрашивал пароль, прежде чем я смогу его использовать. Я докажу серверу, кто я такая, сообщив ему свой пароль.
Еврипид:
Да, это действительно грубо. В такой системе каждый сервер будет должен знать твой пароль. Если в сети тысяча пользователей, каждый сервер должен знать тысячу паролей. Если ты захочешь сменить свой пароль, ты должны связаться со всеми серверами и сообщить им об изменении. Я полагаю, что твоя система не настолько глупа.
Афина:
Моя система не глупа. Она работает так: пароли имеют не только пользователи, но и службы. Каждый пользователь знает свой пароль, а каждая служба знает свой, и есть СЛУЖБА ПРОВЕРКИ ПОДЛИННОСТИ, которая знает ВСЕ пароли – пароли всех пользователей и служб. Служба проверки подлинности хранит эти пароли в единой, централизованной базе данных.
Еврипид:
Ты уже придумала название для этой службы?
Афина:
Пока ещё и не думала об этом. А у тебя есть какие-то варианты?
Еврипид:
Как звали лодочника, перевозившего мёртвых через реку Стикс?
Афина:
Харон?
Еврипид:
Точно. Он не повезёт тебя через реку, если ты не докажешь свою подлинность.
Афина:
Снова ты за старое, Рип. Пытаешься переписать греческую мифологию. Харона не волновала твоя подлинность. Он просто хотел убедиться в том, что ты мёртв.
Еврипид:
Ты можешь предложить что-то лучшее?
Пауза.
Афина:
Ну в общем-то нет.
Еврипид:
Тогда давай назовём службу проверки подлинности "Харон".
Афина:
Договорились. Я думаю, мне следует описать систему?
Предположим, ты хочешь использовать службу, почтовую службу. В моей системе ты не можешь использовать службу, если, э-э, Харон не скажет службе, что ты тот, за кого себя выдаёшь. А ты не получишь разрешения на использование службы, если не докажешь свою подлинность Харону. Когда ты проходишь проверку подлинности Харона, ты должен сказать ему, для какой службы ты хочешь получить разрешение. Если тебе нужен почтовый сервер, ты должен сказать это Харону.
Харон просит тебя подтвердить свою подлинность. Ты делаешь это, предоставив свой секретный пароль. Харон берёт твой пароль и сравнивает его с паролем, заданным для тебя в его базе данных. Если эти пароли совпадают, Харон считают твою подлинность подтверждённой.
Теперь Харон должен убедить почтовый сервер, что ты именно тот, за кого себя выдаёшь. Так как Харон знает пароли всех служб, он знает пароль почтовой службы. А теперь представь, что Харон даст тебе пароль, который ты передашь почтовой службе, подтвердив то, что ты доказал Харону свою подлинность.
Проблема состоит в том, что Харон не может просто дать тебе пароль, так как тогда ты его узнаешь. В следующий раз, когда тебе понадобится почта, ты сможешь обойти Харона и воспользоваться почтовым сервером, минуя проверку подлинности. Ты также можешь представиться кем-то другим и использовать почтовый сервер от имени другого человека.
Поэтому, вместо того, чтобы дать тебе пароль к почтовому серверу, Харон даёт тебе БИЛЕТ к почтовой службе. Этот билет содержит преобразованное имя пользователя, ЗАШИФРОВАННОЕ ПАРОЛЕМ ПОЧТОВОЙ СЛУЖБЫ.
Имея билет, ты можешь обратиться к почтовой службе за своей почтой. Чтобы запросить её, ты сообщишь почтовому серверу, кто ты, и предоставишь билет, подтверждающий, что ты именно тот, за кого себя выдаёшь.
Служба расшифрует билет своим паролем, и, если это ей удастся, она извлечёт имя пользователя, помещённое в билет Хароном.
Затем служба сравнит это имя с именем, посланным тобой вместе с билетом. Если они совпадут, почтовый сервер решит, что твоя подлинность доказана и отдаст тебе твою почту.
Ну и что ты скажешь обо всём этом?
Еврипид:
У меня есть некоторые вопросы.
Афина:
Понятно. Продолжай.
Еврипид:
Когда служба расшифрует билет, как она узнает, что билет расшифрован верно?
Афина:
Я не знаю.
Еврипид:
Наверное, стоит включить в билет имя самой службы. Тогда служба расшифровав билет, сможет понять, что ей это удалось, если найдёт своё имя в расшифрованном билете.
Афина:
Мне это нравится. Таким образом, билет будет выглядеть примерно так:
(Она пишет на листке бумаги:)
БИЛЕТ - {имяПользователя:имяСлужбы}
Еврипид:
Итак, билет содержит только имя пользователя и название службы?
Афина:
Зашифрованные паролем службы.
Еврипид:
Я не думаю, что этого будет достаточно, чтобы сделать билет защищённым.
Афина:
Что ты имеешь в виду?
Еврипид:
Предположим, ты запросила у Харона билет почтовой службы. Харон подготавливает этот билет, в котором прячет твоё имя пользователя "tina". Предположим, что я поймаю этот пакет, когда он будет пролетать по сети от Харона к тебе. Предположим, также, что я смогу убедить свою рабочую станцию, что моё имя пользователя – "tina". Клиентская почтовая программа на моём компьютере будет думать, что я – это ты. Программа отправит от твоего имени украденный билет почтовому серверу. Сервер расшифрует билет и увидит, что он корректный. Имя пользователя в билете совпадает с именем пользователя, пославшего билет. Почтовый сервер отдаёт мне твою почту...
Афина:
Ого! Да, это не хорошо.
Еврипид:
Но мне кажется, я знаю способ решить эту проблему. Или, по крайней мере, частично её исправить. Я думаю, что Харон может включить в изготавливаемый билет больше информации. Помимо имени пользователя, билет также должен включать СЕТЕВОЙ АДРЕС, с которого пользователь запросил у Харона билет. Это даст тебе дополнительный уровень защиты.
Я проиллюстрирую. Предположим, что я опять похитил твой почтовый билет. В билете закодирован сетевой адрес твоего компьютера, и этот адрес не совпадает с адресом моего. Я отправлю от твоего имени ворованный билет почтовому серверу. Служба извлечёт из этого билет имя пользователя и сетевой адрес и попытается сравнить эти данные с именем пользователя и сетевым адресом пославшего этот билет. Имя пользователя совпадает, а сетевой адрес – нет. Сервер отвергает этот билет, так как очевидно, что он был украден.
Афина:
Браво, брависсимо! Ах, почему я не додумалась до этого?
Еврипид:
Ну собственно, для этого и есть я.
Афина:
Итак, билет усовершенствованной конструкции выглядит так:
Я просто восхищена. Давай построим систему Харон и посмотрим, как она работает!
Еврипид:
Не так быстро. У меня есть ещё несколько вопросов к твоей системе.
Афина:
Хорошо. (Афина облокачивается на своё кресло) Стреляй.
Еврипид:
Похоже, что мне придётся получать новый билет каждый раз, когда мне потребуется служба. Если я работаю целый день, вероятно, мне захочется получить мою почту не один раз. Нужно ли мне получать новый билет при каждом обращении за своей почтой? Если да, то мне не нравится эта система.
Афина:
Э-э-э... Ну, вообще-то я не вижу причины не использовать билеты многократно. Если ты получил билет для почтового сервера, ты сможешь использовать его снова и снова. Например, если клиентская почтовая программа формирует запрос к службе от твоего имени, она отправляет почтовому серверу КОПИЮ билета.
Еврипид:
Уже лучше. Но проблемы всё же остались. Ты, кажется, говорила, что я должен передавать Харону свой пароль каждый раз, когда я хочу использовать службу, для которой у меня нет билета. Я вхожу в систему и хочу обратиться к своим файлам. Я запрашиваю у Харона соответствующий билет, а это значит, что я должен использовать мой пароль. Затем я хочу прочитать почту. Ещё один запрос к Харону, и я снова должен вводить пароль. Теперь, скажем, я хочу отправить какое-то письмо на почтовый сервер. Ещё один запрос к Харону и... кажется, ты поняла.
Афина:
Да, я поняла.
Еврипид:
И если этого мало, есть ещё кое-что: похоже, что когда ты доказываешь свою подлинность Харону, ты посылаешь по сети свой секретный пароль открытым текстом. Гении, такие как твой покорный слуга, могут прослушивать сеть и воровать пароли пользователей. Если я узнаю твой пароль, я смогу использовать от твоего имени любую службу. Афина вздыхает.
Афина:
Да, это серьёзные проблемы. Думаю, мне нужно вернуться к доске и порисовать.
Следующее утро, Афина поймала Еврипида за чашечкой кофе. Когда он наливал кофе, она тронула его за плечо.
Афина:
У меня есть новая версия Харона, которая решит наши проблемы.
Еврипид:
В самом деле? Что-то быстро.
Афина:
Да, ты знаешь, такие проблемы не дают мне уснуть.
Еврипид:
Наверное, это угрызения совести. Может попробуем избавиться от них в том небольшом конференц-зале?
Афина:
Почему бы и нет?
Они удаляются в конференц-зал.
Афина:
Я снова начну с описания проблем, но сделаю из них требования к нашей системе.
Афина прочищает горло.
Афина:
Первое требование: пользователи должны вводить пароль только раз, в начале работы на рабочей станции. Это требование подразумевает, что ты не должен вводить пароль каждый раз, когда тебе нужен билет новой службы. Второе требование: пароли не должны передаваться по сети открытым текстом.
Еврипид:
Хорошо.
Афина:
Я начну с первого требования: ты должен использовать свой пароль только раз. Для удовлетворения этого требования я введу новую сетевую службу. Назовём её службой "выдающей билеты", она будет выдавать билеты пользователям, доказавшим Харону свою подлинность. Ты можешь использовать службу, выдающую билеты, если у тебя есть для неё билет – билет на выдачу билета.
Служба, выдающая билеты – это просто версия Харон, так как она также обращается к базе данных Харона. Она является частью Харона, и позволяет тебе доказывать свою подлинность с помощью билета, а не пароля.
Итак, схема проверки подлинности теперь работает так: ты регистрируешься на рабочей станции и используешь программу kinit для связи с сервером Харон. Ты доказываешь свою подлинность Харону и программа kinit получает для тебя билет на выдачу билета.
Теперь, скажем, ты хочешь получить свою почту на почтовом сервере. У тебя ещё нет почтового билета, поэтому ты используешь "билет на выдачу билета", чтобы его получить. Тебе не нужно использовать пароль для получения нового билета.
Еврипид:
Нужно ли мне получать "билет на выдачу билета" каждый раз, когда я захочу обратиться к очередной сетевой службе?
Афина:
Нет. Помнишь, в последний раз мы договорились о том, что билеты могут использоваться многократно. Если ты получил билет на выдачу билета, другой тебе не нужен. Ты можешь использовать билет на выдачу билета для получения всех других билетов.
Еврипид:
Да, это разумно. А так как ты можешь многократно использовать билеты, однажды получив билет для конкретной службы, тебе не нужно запрашивать его снова.
Афина:
Да, не правда ли это элегантно?
Еврипид:
Да, пожалуй, я скоро соглашусь с этим... Если ты скажешь, как не передавать пароли по сети открытым текстом, запрашивая билет на выдачу билета.
Афина:
Как я и сказала, эту проблему я также решила. Когда я сказала, что ты должен связаться с Хароном, чтобы получить билет на выдачу билета, это прозвучало так, как будто ты должен передать серверу Харон по сети пароль открытым текстом. Но это вовсе не так.
Вот, что происходит на самом деле. Когда ты с помощью программы kinit получаешь билет на выдачу билета, kinit не отправляет серверу Харон твой пароль, kinit посылает только имя пользователя.
Еврипид:
Прекрасно.
Афина:
Харон находит в своей базе твой пароль. Затем Харон создаёт пакет данных, содержащий билет на выдачу билета. Прежде чем послать его тебе, Харон шифрует содержимое пакета твоим паролем.
Твой компьютер получает пакет с билетом. Ты вводишь свой пароль. Kinit пытается расшифровать билет введённым паролем. Если kinit сможет это сделать, ты успешно проходишь проверку подлинности Харона. Теперь у тебя есть билет на выдачу билетов, и с его помощью ты можешь получить все остальные требуемые билеты.
Ну и что ты скажешь об этом полете мысли?
Еврипид:
Пока не знаю... Я пытаюсь подумать. Знаешь, мне кажется, что части описанной тобой системы работают достаточно хорошо. Я должен доказывать твоей системе свою подлинность только один раз. Затем Харон может выдавать мне билеты служб, не причиняя мне неудобств. Безукоризненно с этой точки зрения. Но кое-что беспокоит меня в конструкции билетов служб. Что-то нужно сделать с тем, что их можно использовать повторно. Да, я согласен с тем, что они должны быть многократного использования, но такие билеты по своей природе очень опасны.
Афина:
Что ты имеешь в виду?
Еврипид:
Взгляни на это. Предположим, ты работаешь на незащищённом компьютере. Во время сеанса работы ты получила билет к почтовой и файловой службе, а также к службе печати. Теперь, предположим, что при выходе ты оставишь эти билеты на этом компьютере.
После чего зарегистрируюсь я и найду эти билеты. По мне видно, что я способен на многое, поэтому я заставлю рабочую станцию думать, что я – это ты. Так как билеты выпущены на твоё имя, я могу использовать почтового клиента для обращения к твоей почте, файлового клиента для просмотра и удаления твоих файлов, а ещё могу напечатать столько, что тебе придётся за это дорого заплатить. И всё потому, что билеты были случайно оставлены на компьютере.
И ничто не помешает мне скопировать эти билеты к себе. Я смогу продолжать использовать их целую вечность.
Афина:
Но это легко исправить. Мы просто напишем программу, уничтожающую билеты пользователей после каждого сеанса. Ты не сможешь использовать уничтоженные билеты.
Еврипид:
Тогда очевидно, в твоей системе должна работать программа, уничтожающая пакеты, но будет глупо заставлять пользователей рассчитывать на неё. Ты не можешь полагаться на то, что пользователи не будут забывать уничтожать свои пакеты перед завершением сеанса работы. И даже если ты рассчитываешь на это, рассмотри следующий сценарий.
У тебя есть программа, которая следит за сетью и отлавливает билеты службы, пролетающие по сети. Предположим, я выбрал тебя в качестве жертвы. Я подожду, когда ты начнёшь сеанс работы, включу свою программу и выловлю кучу твоих билетов.
Я дождусь, когда ты закончишь свою работу, и, в конце концов, выйдешь из системы и уйдёшь. Я поиграюсь с сетевой программой моего компьютера и изменю его адрес так, что он будет равен адресу твоей рабочей станции, на которой ты работала, пока я перехватывал пакеты. Я заставлю свой компьютер поверить в то, что я – это ты. У меня есть твои билеты, твоё имя пользователя и правильный сетевой адрес. Я могу ВОСПРОИЗВЕСТИ эти пакеты и использовать службы от твоего имени.
И меня не будет волновать, уничтожила ли ты пакеты, завершая сеанс работы на компьютере. Украденные мной билеты будут верны столько времени, сколько я буду их использовать, так как в сегодняшней конструкции билетов не ограничено ни количество использований, ни срок действия билета.
Афина:
Я поняла, к чему ты клонишь! Билеты не могут использоваться вечно, так как это представляет большую угрозу безопасности. Мы должны ограничить период использования билета, возможно, для каждого билета следует назначать дату окончания срока действия.
Еврипид:
Точно. Я думаю, что в каждый билет нужно включить ещё два блока данных: срок жизни, определяющий интервал действия билета, и отметку времени, состоящую из даты и времени, когда Харон выдал билет. С учётом этого билет будет выглядеть так:
Теперь, когда служба расшифрует билеты, она сравнит имя пользователя и адрес в билете с именем и адресом пославшего билет, а также, проверив отметку времени и время жизни, определит годность билета.
Афина:
Всё правильно. Но какой срок жизни должен иметь обычный билет службы?
Еврипид:
Не знаю. Вероятно длительность обычного сеанса работы. Скажем, восемь часов.
Афина:
То есть, если я просижу за своим компьютером больше восьми часов, срок всех моих билетов истечёт. В том числе и моего билета на выдачу билета. И мне придётся повторно пройти проверку подлинности Шарона через восемь часов.
Еврипид:
Это довольно разумно, разве нет?
Афина:
Я думаю, да. Итак, мы решили, что срок действия билетов будет истекать через восемь часов. Теперь и у меня есть вопрос для тебя. Предположим, что я выловлю в сети ТВОИ билеты...
Еврипид:
(Делая удивлённые глаза) О, Афина! Но ты же не будешь этого делать?
Афина:
Только в качестве аргумента. Я скопировала твои билеты. Затем я дождусь, пока ты выйдешь из системы. Скажем, у тебя намечен визит к врачу или тебе нужно провести занятия, и ты завершил сеанс работы на компьютере через пару часов. Ты конечно умён и разрушил перед выходом копии своих билетов.
Но я украла твои билеты, и они будут действовать еще шесть часов. Этого времени мне будет вполне достаточно, чтобы украсть твои файлы и напечатать тысячу копию чего-нибудь от твоего имени.
Механизм со сроком жизни и отметкой времени хорошо работает только тогда, когда укравший билеты решить воспроизвести их по истечении срока действия. Но если он сможет воспроизвести их до этого...
Еврипид:
Ну хорошо... Ты, конечно же, права.
Афина:
Я думаю, мы столкнулись с большой проблемой. (Она вздыхает.)
Пауза.
Еврипид:
По-моему это значит, что ты будешь занята сегодня ночью. Хочешь ещё кофе?
Следующее утро в офисе Еврипида. Афина стучит в дверь.
Еврипид:
Сегодня утром у тебя мешки под глазами.
Афина:
Да, и ты знаешь почему. Ещё одна из этих длинных ночей.
Еврипид:
Ты решила проблему воспроизведения?
Афина:
Думаю, да.
Еврипид:
Присядь.
Она садится.
Афина:
Как обычно, мне кажется, что нужно перефразировать проблему. Билеты можно использовать в течение ограниченного времени, скажем, восьми часов. Если кто-то украдёт твои билеты и захочет воспроизвести их до того, как истечёт срок их действия, мы никак не сможем его остановить.
Еврипид:
Да, это проблема.
Афина:
Мы сможем разрешить эту проблему, если наши билеты не будут использоваться многократно.
Еврипид:
Но тогда тебе придётся получать новый билет для каждого обращения к сетевой службе.
Афина:
Правильно. Это, мягко говоря, грубое решение. (Пауза.) Э-э, как же мне доказать свою правоту? (Она на мгновение задумалась.)
Всё правильно, я еще раз перефразирую проблему, на этот раз в форме требования. Сетевая служба должна иметь возможность определить, что человек, предоставляющий билет - именно тот, кому этот билет был выдан.
Позволь мне ещё раз проанализировать процесс проверки подлинности, и найти подходящий способ для иллюстрации моего решения этой проблемы.
Я хочу использовать какую-то сетевую службу. Я обращаюсь к этой службе, запустив на своей рабочей станции клиентскую программу. Клиент передаёт серверу три вещи: моё имя, сетевой адрес моего компьютера и соответствующий билет службы.
Билет содержит имя человека, которому он был выдан и адрес компьютера, на котором этот человек запрашивал билет. Он также содержит дату окончания действия в виде срока жизни и отметки времени. Вся эта информация зашифрована паролем службы, выданным Хароном.
Эта схема проверки подлинности полагается на следующие проверки:
Может ли служба расшифровать билет?
Не просрочен ли билет?
Соответствует ли имя и адрес компьютера, указанные в билете, имени и адресу человека, пославшего этот билет?
Что доказывают эти проверки? Первая проверка доказывает, что билет был получен от Харона. Если билет не расшифровывается, он получен не от настоящего Харона. Настоящий Харон зашифровал бы этот билет паролем службы. Только Харон и служба знают пароль службы. Если билет расшифрован успешно, служба точно знает, что он получен от Харона. Эта проверка предотвращает подделку билетов Харона.
Вторая проверка проверяет срок жизни и отметку времени. Если билет просрочен, служба его не принимает. Эта проверка не даёт людям использовать старые билеты, так как они, вероятно, были украдены.
Третья проверка сравнивает имя и адрес пользователя билета с именем и адресом, указанным в билете. Если они не совпадают, пользователь билета получил (возможно, незаконно) билет другого человека. Такой билет, конечно, также не принимается.
Что доказывает эта проверка, если имя и адрес совпали? Ничего. Мошенники могут украсть пакеты при передаче по сети, сменить адреса и имена пользователей, и ограбить ресурсы других пользователей. Как я и сказала вчера, пакеты можно воспроизводить, пока срок их действия не истечёт. Они могут быть воспроизведены, потому что служба не может определить, является ли человек, посылающий билет, действительным его владельцем.
Служба не способна это определить, так как у неё нет общего секрета с пользователем. Взгляни на это. Если я охраняю Эльсинор, как ты знаешь, это замок в Гамлете, и ты хочешь сменить меня, я не должна пускать тебя на своё место, если ты не скажешь мне верный пароль. Вот пример, когда мы вдвоем знаем общий секрет. И, вероятно, этот секрет кто-то придумал для всех стоящих на посту.
Об этом я и думала ночью, почему бы Харону не создать пароль, который разделят законный владелец ключа и служба? Харон даст одну копию этого ключа сеанса службе, а другую копию – пользователю. Когда служба получит билет от пользователя, она сможет проверить подлинность пользователя с помощью этого ключа.
Еврипид:
Подожди-ка. Как Харон собирается передавать обеим сторонам ключ сеанса?
Афина:
Владелец билета получит ключ сеанса, включённый в ответ от Харона. Например, так:
Она пишет мелом на доске:
ОТВЕТ ХАРОНА - [ключСеанса|билет]
Копия ключа сеанса службы передаётся внутри билета, и служба получит этот ключ, когда расшифрует билет. Таким образом, билет будет выглядеть так:
Когда ты захочешь обратиться к службе, запущенная клиентская программа создаст то, что я назову АУТЕНТИФИКАТОРОМ. Аутентификатор содержит твоё имя и адрес твоего компьютера. Клиент шифрует эту информацию ключом сеанса, тем, что он получил вместе с билетом.
Создав аутентификатор, клиент посылает его службе вместе с билетом. Служба ещё не может расшифровать аутентификатор, так как у неё нет ключа сеанса. Этот ключ находится в билете, поэтому сначала служба расшифровывает билет.
Расшифровав его, служба получает следующую информацию:
Срок жизни и отметка времени билета;
Имя владельца билета;
Сетевой адрес владельца билета;
Ключ сеанса.
Служба может проверить, не просрочен ли билет. Если в этом отношении всё хорошо, служба расшифровывает аутентификатор с помощью ключа сеанса. Если ей это удаётся, служба получает имя пользователя и сетевой адрес. Служба сравнивает эти данные с именем и адресом, находящимися в билете, а ТАКЖЕ с именем и адресом человека, отправившего этот билет и аутентификатор. Если всё сходится, служба определяет, что человек, отправивший этот пакет – действительно настоящий его владелец.
Афина делает паузу, прочищает горло, делает глоток кофе.
Я думаю, что механизм с ключом сеанса и аутентификатором решает проблему воспроизведения.
Еврипид:
Может быть. Но подожди... Чтобы взломать эту версию систему, я должен иметь подходящий для службы аутентификатор.
Афина:
Нет. Ты должен иметь аутентификатор И билет этой службы. Аутентификатор ничего не стоит без билета, потому что служба не сможет его расшифровать, не получив подходящего ключа сеанса, а ключ сеанса она не получит, не расшифровав сначала билет.
Еврипид:
Хорошо, это я понял, но разве ты не сказала, что когда клиентская программа связывается с сервером, она отправляет билет и соответсвующий аутентификатор вместе?
Афина:
Да, я говорила это.
Еврипид:
И если это так на самом деле, что помешает мне перехватить вместе с билетом ещё и аутентификатор? Я уверен, что смогу написать такую программу. Если у меня будет билет и аутентификатор к нему, я думаю, что смогу использовать их вместе, пока не закончится срок действия билета. Мне просто нужно правильно изменить адрес моей рабочей станции и имя пользователя. Так?
Афина:
(Кусая губы) Так. Как печально.
Еврипид:
Подожди, подожди, подожди! Это не такая уж большая проблема. Билеты могут использоваться многократно, пока не истечёт их срок, но это не значит, что аутентификаторы также должны использоваться повторно. Предположим, что мы разработаем систему, в которой аутентификаторы могут использоваться только раз. Это нам что-нибудь даст?
Афина:
Возможно. Давай посмотрим, клиентская программа создаёт аутентификатор, затем отправляет его службе вместе с билетом. Ты перехватываешь билет с аутентификатором, когда они передаются от компьютера серверу. Но сервер получит и билет, и аутентификатор, прежде чем ты отправишь свои копии. Если аутентификатор применяется только раз, твоя копия не подойдёт, и попытка воспроизвести билет с аутентификатором окончится неудачей.
Да, это нас спасёт. Получается, что нам осталось придумать способ сделать аутентификатор одноразовым.
Euripides:
Нет проблем. Давай просто поместив в него срок жизни и отметку времени. И пусть срок жизни аутентификатора будет ограничен парой минут. Когда ты захочешь использовать службу, твоя клиентская программа создаст аутентификатор, отметит в нём текущее время и отправит его серверу вместе с билетом.
Сервер получит билет вместе с аутентификатором и займётся своим делом. Когда сервер расшифрует аутентификатор, он проверит его время жизни и отметку времени. Если аутентификатор не просрочен и всё остальные проверки пройдены, сервер решит, что ты прошла проверку подлинности.
Предположим, что я скопировал аутентификатор и билет, когда они передавались по сети. Я должен будет изменить сетевой адрес моего компьютера и своё имя пользователя, и проделать это за пару минут. Это будет довольно сложно. На самом деле, я думаю, что это невозможно. Хотя...
Да, здесь ещё одна потенциальная проблема. Предположим, что я не буду перехватывать пакет с аутентификатором передаваемый от твоей рабочей станции серверу, а перехвачу оригинальный билет, отправленный Хароном, который ты получила в ответ на запрос билета.
Насколько я помню, в нём содержится ключ сеанса: один для тебя и другой для службы. Ключ службы скрыт в билете и получить его я не смогу, но как быть с другим, который используется для построения аутентификаторов?
Если я смогу получить копию ключа сеанса, я смогу создать собственные аутентификаторы, а если я их создам, я смогу взломать систему.
Афина:
Да, я думала об этом ночью, но затем я проанализировала процесс получения билетов и поняла, что украсть аутентификаторы таким способом невозможно.
Ты садишься за рабочую станцию и с помощью программы kinit получаешь билет на выдачу билетов. Kinit запрашивает у тебя имя пользователя, и когда ты его вводишь, kinit отправляет это имя Харону.
Харон использует это имя для поиска твоего пароля, а затем создаёт для тебя билет на выдачу билета. В ходе этого процесса Харон создаёт ключ сеанса, который ты разделишь со службой выдачи билетов. Харон помещает одну копию этого ключа сеанса в билет на выдачу билета, а другую в пакет с билетом, который ты должен получить. Но прежде чем послать тебе этот пакет, Харон шифрует всё это твоим паролем.
Харон посылает пакет по сети. Кто-то может перехватить это пакет, но он не сможет с ним что-либо сделать, так как пакет зашифрован твоим паролем. Получается, что никто не может украсть ключ сеанса на выдачу билета.
Kinit получает пакет с билетом и предлагает тебе ввести пароль, что ты и делаешь. Если ты вводишь верный пароль, kinit может расшифровать пакет и дать тебе твою копию ключа сеанса.
Теперь, когда ты разобрался с механизмом kinit, ты хочешь получить свою почту. Ты запускаешь программу почтового клиента. Эта программа ищет билет для почтовой службы и не находит его (до этого ты не обращался за почтой). Чтобы получить билет к почтовой службе у службы выдачи билетов, клиент должен использовать билет на выдачу билетов.
Клиент создаёт аутентификатор для транзакции получения билета и шифрует его своей копией ключа сеанса выдачи билета. Затем клиент передаёт Харону аутентификатор, билет на выдачу билета, твоё имя, адрес твоего компьютера и имя почтовой службы.
Служба выдачи билетов получает всё это и выполняет проверки подлинности. Если всё проходит хорошо, служба выдачи билетов получает копию ключа сеанса, который она разделяет с тобой. Затем служба выдачи билетов строит билет для почтовой службы, при этом она создаёт для тебя новый ключ сеанса, который ты разделишь с почтовой службой.
После этого служба выдачи билета подготавливает к передаче твоему компьютеру пакет с билетом. Этот пакет содержит билет и твою копию ключа сеанса почтовой службы. Но прежде чем отправить пакет, служба выдачи билетов шифрует его своей копией ключа сеанса ВЫДАЧИ БИЛЕТОВ. Сделав это, она отправляет пакет.
Итак, мы наблюдаем пакет с билетом почтовой службы, передающийся по сети. Предположим, что какой-то сетевое чудовище перехватит его. Чудовищу не повезёт, та как пакет зашифрован ключом сеанса выдачи билета, а ключ известен только тебе и службе выдачи билетов. Так как это чудовище не сможет расшифровать пакет с почтовым билетом, оно не сможет получить КЛЮЧ ПОЧТОВОГО СЕАНСА. Без этого ключа сеанса, оно не сможет использовать ни один из билетов почтовой службы, которые вы будете пересылать по сети.
Я думаю, что мы защищены. А как ты считаешь?
Еврипид:
Возможно.
Афина:
Возможно! Это всё, что ты можешь сказать!
Еврипид:
(смеясь) Не расстраивайся. Тебе уже следует знать меня лучше. Не пойми меня превратно, но мне кажется, что ты не спала полночи.
Афина:
Хм-м-м!
Еврипид:
Ну хорошо, три четверти. Вообще-то система становится приемлемой. Механизм с ключом сеанса решает проблему, о которой я думал этой ночью: проблему взаимной проверки подлинности.
Пауза.
Не будешь возражать, если я поговорю минутку?
Афина:
(Немного холодно) Будьте так любезны.
Еврипид:
Ты так добра. (Еврипид прочищает горло.) Этой ночью, наблюдая в своей голове за пляской аутентификаторов и ключей сеансов, я попытался обнаружить новые проблемы этой системы, и обнаружил ещё одну, весьма серьёзную. Я опишу её тебе в следующем сценарии.
Предположим, что ты устала от своей работы и решила, что лучше поискать себе другое место. Ты хочешь напечатать своё резюме на шустром лазерном принтере компании, чтобы кадровые агент и потенциальные работодатели могли узнать о твоём профессионализме.
Итак, ты вводишь команду печати и указываешь, что резюме нужно отправить на определённый принт-сервер. Эта команда получает требуемый билет службы (если у тебя его ещё нет), затем посылает этот билет с твоим именем подходящему серверу печати. По крайней мере, ты считаешь, что именно ему. Но на самом деле ты не можешь гарантировать, что он дойдёт до нужного сервера печати.
Предположим, что какой-то нечистоплотный хакер, скажем, твой босс, перенастроил всю систему так, что твой запрос вместе с билетом попадёт к почтовому серверу в его кабинете. Его службу печати не волнует билет и его содержимое. Она отбросит пакет и отправит твоему компьютеру сообщение о том что, билет прошёл осмотр, и сервер готов и хочет распечатать твоё задание. Команда печати отправляет задание фальшивому серверу печати и враг получает твоё резюме.
Я опишу эту проблему с другой стороны. Без ключей сеанса и аутентификаторов Харон может защитить сервера от фальшивых пользователей, но он не мог защитить пользователей от фальшивых серверов. Нашей системе не хватает механизма проверки подлинности сервера до передачи ему важной информации. Система должна обеспечивать взаимную проверку подлинности.
Но ключ сеанса решает эту проблему, если разработать клиентские программы правильно. Вернёмся к сценарию с сервером печати. Мне нужна клиентская программа печати, которая убедится в законности службы, которой она посылает задания.
Вот что эта программа должна делать. Я ввожу команду печати и указываю имя файла с моим резюме. Предположим, что у меня есть билет службы печати и ключ сеанса. Программа клиента использует этот ключ сеанса для создания аутентификатора, затем отправляет аутентификатор вместе с билетом "предполагаемому" почтовому серверу. Клиент ещё НЕ отправил резюме, он ждёт ответа от службы.
Настоящая служба получает билет и аутентификатор, расшифровывает пакет и извлекает из него ключ сеанса, после чего использует ключ сеанса для расшифровывания аутентификатора. Сделав это, служба проводит все необходимые проверки подлинности.
Предположим, что проверки подтвердили мою подлинность. Теперь сервер готовит пакет ответа, чтобы доказать свою подлинность клиентской программе. Он шифрует этот пакет ключом сеанса, а затем возвращает его ожидающему клиенту.
Клиент получает пакет и пытается расшифровать его моим ключом сеанса. Если пакет расшифрован верно, и в нём содержится корректный ответ сервера, моя клиентская программа точно знает, что сервер, зашифровавший пакет – настоящий. После этого клиент отправляет задание с резюме службе печати.
Предположим, что мой босс перенастроил всё так, что его почтовый сервер изображает из себя нужный мне. Мой клиент посылает аутентификатор и билет "службе печати" и ждёт ответа. Фальшивая служба печати не может ответить корректно, так как она не может расшифровать билет и получить ключ сеанса. Мой клиент не отправит задание, пока он не получит верного ответа. В конце концов, клиент прекращает ожидание и завершает свою работу. Моё задание печати не выполняется, но, по крайней мере, моё резюме не попало на стол врагу.
Ты знаешь, мне кажется, что у нас есть солидный фундамент для реализации системы проверки подлинности Харон.
Афина:
Возможно. Всё равно, мне не нравится название "Харон".
Еврипид:
Нет? С каких это пор?
Афина:
А оно мне никогда не нравилось, потому что это название лишено смысла. Я говорила вчера об этом со своим дядюшкой Аидом, и он предложил мне другое имя, имя трёхглавого сторожевого пса.
Еврипид:
Ты имеешь в виду Цербера?
Афина:
Прикуси свой язык, Рип! Скажешь тоже, Цербер...
Еврипид:
А разве его звали по-другому?
Афина:
Да, если бы ты был римлянином! Я греческая богиня, он греческий сторожевой пёс, и его имя "Kerberos," "Kerberos" с буквой K.
Еврипид:
Ладно, ладно, не надо метать молнии. Я соглашусь с этим именем. Вообще-то, в нём что-то есть. Адью Харон и здравствуй Kerberos.
Этот диалог был написан в 1988 г. с целью разъяснить читателям основные причины создания протокола Kerberos V4 и его принципы. Все эти годы он делал это очень здорово.
Когда я преобразовывал этот документ в HTML, я был удивлён, насколько этот документ по-прежнему актуален для протокола Kerberos V5. Хотя изменилось многое, основные идеи протокола остались неизменными. На самом деле, протокол Kerberos V5 отличается от описания протокола "Kerberos" в этом диалоге всего в двух местах.
Первое изменение было вызвано пониманием того, что небольшой пятиминутный интервал не спасает от атак нападающего, который с помощью программы может автоматически перехватить пакет и аутентификатор, а затем немедленно отправить их и осуществить атаку воспроизведением.
В Kerberos V5, аутентификаторы сделаны действительно одноразовыми, для этого на серверах, принимающих билеты, создан "кэш повторов", в котором фиксируются последние полученные сервером аутентификаторы. Если нападающий попытается ухватить аутентификатор и повторно его использовать, даже в пределах приемлемых пяти минут, кэш повторов сможет определить, что сервер уже получал этот аутентификатор.
Вторым основным изменением протокола стал отказ от шифрования билета паролем пользователя, когда во время первоначального обмена билетами билет передаётся от сервера Kerberos программе kinit. Этот билет уже зашифрован секретным ключом службы выдачи билетов, тем более, что когда он позже используется для получения других билетов, он не шифруется паролем. Таким образом, нет смысла шифровать билет ещё раз паролем пользователя. (Остальная часть ответа сервера Kerberos пользователю, содержащая ключ сеанса выдачи билетов, конечно же, шифруется паролем пользователя.)
Похожее изменение было внесено в протокол службы выдачи билетов (TGS); билеты, выдаваемые TGS, больше не шифруются ключом службы выдачи билетов, так как они уже зашифрованы секретным ключом сервера приложений. Если пакет в Kerberos V4 выглядел так:
Конечно, в Kerberos V5 появилось и много новых возможностей. Теперь пользователь могут переправлять свои билеты, чтобы они могли работать в другом сетевом окружении; кроме этого, могут делегировать часть своих прав серверу, что позволяет серверу действовать от имени пользователя в качестве посредника. Также появилась возможность заменить алгоритм DES более защищённым криптографическим алгоритмом, например тройным DES. Читателям, которых заинтересовали отличия между Kerberos V4 и V5, будет полезно прочитать статью The Evolution of the Kerberos Authentication System, написанную Клиффом Ньюманом (Cliff Neumann) и Теодором Цо (Theodore Ts'o).
Я надеюсь, что вам понравилось это маленькое введение в протокол Kerberos. Желаю вам удачи в ваших будущих исследованиях!
С комментариями и предложениями относительно этой статьи, пишите: tytso@mit.edu
С комментариями и предложениями относительно перевода этой статьи, пишите: info@inventa.ru
