| Рубрикатор |  |
 |
| Статьи |  |
ИКС № 12 2007 | |
|
| Сергей РЯБКО В.А. СМЫСЛОВ | 09 января 2008 |
Безопасность IP: таинство творения
Сегодня, когда в мире идет повсеместная IP-зация телекоммуникационных структур, защищенность IP – проблема номер один. 15 лет назад Internet Engineering Task Force начал создавать архитектуру обеспечения безопасности протокола IP. Приоткрыть окно в творческую лабораторию IETF взялись свидетели событий в рабочей группе IP-sec.
С.Д. Рябко, генеральный директор "С.-Терра СиЭсПи", канд. физ.-мат. наук
Сквозь технические детали архитектуры прорисованы контуры конкретных событий: какие люди и как создавали стандарт, как и почему принимались те или иные решения, как судьбы технических спецификаций тесно переплетались с судьбами людей, как и каким образом влияли на принятие тех или иных спецификаций большие экономические интересы игроков рынка, политические факторы, гениальные догадки и простые человеческие ошибки.
Грядет IPv6!
В конце 80-х - начале 90-х годов прошлого века интернет-сообщество с энтузиазмом взялось за обновление протокола IP. Была поставлена задача обеспечения безопасности IP. Разрабатываемый протокол называли IP:TNG (что означало Internet Protocol: The Next Generation, сокращенно IPng), а ныне его именуют IPv6.
Зарождение
Мероприятие IETF с романтическим названием Birds of a Feather (BoF), т.е. «птицы с одинаковыми перьями», представляет собой дискуссию в начале исследования проблемы, когда еще не вполне очевидно, стоит ли создавать для ее решения рабочую группу (РГ). IETF назначает руководителя BoF и создает список почтовой рассылки. На 24-й сессии IETF, состоявшейся в июле 1992 г., была созвана BoF IPsec. Ее первый председатель Элтон Гувер сформулировал задачу и анонсировал ориентировочный план работы РГ. Сопредседателями РГ, сформированной 17 июня 1993 г., стали Гувер и Пол Ламберт.
Гувер предполагал, что проект стандарта архитектуры IPsec появится в марте 1993 г., протокол управления ключами - еще через год, а полный набор стандартов - летом 1994 г. Однако задача оказалась «вязкой», и к плановому сроку завершения работ неопределенность только возросла. Из протокола заседания 29-й сессии IETF (конец марта - начало апреля 1994 г.):
«Поступило много спецификаций [протоколов] защиты сетевого уровня (SP3-N, SP3-A, SP3-I, SP3-D, SP3-C, NLSP, I-NLSP, swIPe, PIP и проч.), но согласия по поводу проекта нет. Также представлено много реализаций разного рода защиты для протокола IP (ANS, AT&T, DEC, Hughes, Morningstar, Motorola, Semaphore, UUNET, Qualcomm и др.). Однако пока ни одна из них не совместима ни с одной другой».
Обратите внимание на то, какие игроки делали ставки: AT&T, DEC, Hughes, Motorola. Это - флагманы индустрии, за которыми стояли деньги, рынки и связи с правительством США, занимавшим неоднозначную позицию по отношению к криптографическим технологиям. Работа РГ усложнялась не только по техническим, но и по коммерческим и политическим причинам. К тому же народ в РГ «подобрался душевный, можно сказать - деликатный». Группа была проблемной, взрывоопасной и неоднократно оказывалась на грани кризиса и даже полного фиаско.
Отцы и отчимыСудьба Гувера как сопредседателя РГ не задалась. В январе 1994 г. его сменил Джим Змуда, а затем Рэндалл Аткинсон. Собственно, Ламберт с Аткинсоном и привели РГ к созданию первой версии стандарта. И если к вольному сообществу IETF применимы административные чины, Ламберт был скорее «исполнительным директором», а Аткинсон - «техническим директором».
Ламберт стал сопредседателем группы во времена его работы в Motorola. Вскоре он перешел в Oracle, что придало его позиции нейтральность, поскольку Oracle была мало заинтересована в IPsec. Аткинсон, напротив, из Naval Research Laboratory перешел в «заинтересованную» Cisco Systems. Он активно формировал требования к нарождающейся архитектуре, редактировал стандарты первого (RFC 1825) и второго (RFC 2401) поколений IPsec, дорабатывал их в течение десятилетия. Однако редактирование председателем рабочих документов - не в традициях IETF, и Аткинсон передал эти функции Стивену Кенту. Тот 25 лет проработал в BBN, дойдя до поста вице-президента компании, был участником многих крупных информационных проектов, членом нескольких РГ IETF, преподавателем и автором книг о сетевой защите.
Неоспоримой заслугой Аткинсона стало обеспечение версионной совместимости IPsec по отношению к протоколу IP. Рэндалл отстаивал свои убеждения, несмотря на всеобщую эйфорию по поводу IPv6. Мудрый Аткинсон! Если бы не его предусмотрительность и настойчивость, проект оказался бы лишь «мертвым» дополнением к IPv6, и поныне находящемуся в послеродовой коме.
Основы основСреди важных архитектурных вопросов числился выбор принципа «упаковки» защищенных данных и служебной информации в IP-пакет. Как это сделать? Расширить заголовок IP-пакета, дополнив его параметрами защиты, или инкапсулировать защищенный пакет внутрь нового IP-пакета? Одним из тех, кто первым отметил преимущества туннелирования, был Фил Карн. Еще в 1992 г. он писал:
«Протокол защиты IP должен быть просто другим протоколом, который «лежит» поверх IP... В этом ключе он может быть независимым от версии IP».
О Карне следует рассказать особо. Он привнес в IPsec больше свежих идей, чем кто-либо другой. Фил был близок к радио и «железу», поэтому ему была присуща свойственная дизайнерам встроенного ПО страсть к оптимизации кода. Карну принадлежит личный рекорд производительности шифрования DES на неспециализированном процессоре - около 15 Мбит/с (на 386-й машине в 1995 г.). Он разработал едва ли не первый доступный в исходном коде стек TCP/IP для радиоустройств KA9Q. И еще одна замечательная особенность Фила: создавая логическую конструкцию, он тут же сам прототипировал протокол в коде. Это крайне важно для дизайна протоколов, поскольку придает решениям реалистичность и жизненную силу.
Первое издание: IPsec - AH + ESP
Собственно, IPsec состоит из двух групп протоколов - защиты данных и управления ключами. Для защиты разрабатывали два протокола: AH (Authentication Header) предназначался для аутентификации и контроля над целостностью данных, а ESP (Encapsulating Security Payload) обеспечивал конфиденциальность, аутентификацию и контроль над целостностью.
И хотя эти протоколы много проще протоколов управления ключами, работа шла тяжело. Дизайн часто менялся, иногда претерпевая полный круг разработки. Так, первоначально ESP обеспечивал конфиденциальность, аутентификацию и контроль над целостностью. Затем его решили упростить, изъяв аутентификацию/целостность и предложив использовать для этой цели AH. Однако связка AH+ESP оказалась более сложной и пришлось вернуться к начальному варианту ESP.
Немало времени отняла дискуссия о криптоалгоритмах. Бурное развитие криптоанализа в те годы то и дело размывало основания, на которых строила свои конструкции рабочая группа.
Тягостность разработки, никак не влезающей в плановые сроки, и нерешенность задач ключевого управления привели к тому, что в 1995 г. было принято политическое, но лишенное практической ценности решение: хоть как-то зафиксировать наработанный результат. В результате AH и ESP были опубликованы в RFC 1825-1829 без протокола управления ключами.
КЛЮЧЕВАЯ ПРОБЛЕМАДаешь управление ключами!
Mеханизмы шифрования бесполезны без криптоключей. Управление ключами должно обеспечивать:
- установление ключа - генерацию ключа и его доставку потребителю;
- аутентификацию - доказательство того, что в обмене участвуют стороны, которые владеют соответствующими секретами;
- симметрию - равную способность каждой из сторон создавать ключи для защищенного обмена;
- защиту сеансового ключа - невозможность расшифровать ранее защищенный сеансовыми ключами трафик даже в случае компрометации долговременного секрета;
- независимость сеансовых ключей - невозможность расшифровать трафик, зашифрованный с помощью сеансового ключа i, даже если ключи «смежных» сеансов i-1 и i+1 скомпрометированы.
Решить задачу управления можно двумя способами: интегрировать протокол ключевого управления с протоколом защиты информации (in-band key management) или выделить функции ключевого управления в отдельный протокол (out-of-band key management). С подачи того же Карна еще в 1992-1993 гг. РГ IPsec сориентировалась на второй вариант, но это предложение было оспорено самым неожиданным и решительным образом.
Вот вам SKIP!Пока IETF работал над спецификациями, корпорация Sun Microsystems готовила новую ставку в игре за безопасность. Она разрабатывала протокол SKIP (Simple Key Management for Internet Protocol), интегрирующий функции защиты и управления ключами, и создавала основанный на нем коммерческий продукт. Разработку вел молодой талантливый криптограф, пакистанец по происхождению Ашар Азиз при поддержке самого Витфилда Диффи - одного из авторов криптографии с открытым ключом. Спецификация SKIP была предложена РГ IPsec летом 1994 г., и к ее продвижению были приложены значительные усилия. А через год, на 33-й сессии IETF, были представлены три независимые реализации SKIP, две из которых (компаний Sun и российской «ЭлвисПлюc») являли собой коммерческие продукты, а третья (созданная Swiss Federal Institute of Technology) - открытую справочную реализацию (public domain reference implementation).
Торговля в храме
Формально протоколы IETF представляют собой общедоступные стандарты. Большинство из них разрабатываются без коммерческой подоплеки, но с протоколом SKIP связана история, для IETF нехарактерная. «Выход» Sun одновременно с проектом стандарта и коммерческим продуктом дал эффект взрыва. К тому же Sun попыталась защитить свои позиции платным патентом, и хотя она быстро осознала, что это - перебор, и отказалась от патентных претензий, рынок уже напрягся. IBM и Cisco Systems, озабоченные выпадом Sun, начали контратаку, предложив альтернативные стандарты.
Среди них заслуживают упоминания три: протокол Photuris («Светлячок») Фила Карна, IKMP - вскоре проигранная попытка IBM войти в игру (потом корпорация поддержала Photuris) и ISAKMP (Intermet Security Association and Key Management Protocol), вышедший из недр NSA (Национальное агентство безопасности США), а впоследствии поддержанный Cisco и IBM.
Поначалу по техническим качествам протоколов управления ключами лидировал Photuris. Он наилучшим образом соответствовал требованиям IETF, и его «вели» квалифицированные и достаточно энергичные люди. Но и SKIP в этой гонке шел с хорошим запасом скорости: он был прототипирован в готовом продукте и подкупающе прост. А альтернативные решения, в частности ISAKMP, подвергались заслуженной критике за их сложность.
ГЕНЕЗИС ТЕХНОЛОГИИО простом и сложном
В июньском протоколе IETF 1994 г. значилось:
«Стив Белловин представил собственные требования к протоколу управления ключами: ...согласование [параметров управления ключами] должно быть настолько простым и минимизированным, насколько это возможно».
Стивен Белловин занимал особое место не только в РГ IP-sec, но и в IETF. Инженер и ученый, блестящий аналитик и практик, дизайнер и технический писатель, он выступал в группе IPsec скорее в роли научного оппонента, выполняя «госприемку» технологии IP-sec. И его явно не устраивали «некрасивые самолеты». Из отчета 33-й сессии IETF от 1995 г.:
«Группе IPsec был представлен протокол управления ключами ISAKMP. Его в целом одобрили, хотя Стивен Белловин отметил, что технология является чересчур гибкой (too flexible)».
В сухой протокол просочилась ирония Белловина: «чересчур гибкой»! Однако дизайн простых решений много труднее, чем дизайн сложных. А до относительно простой сбалансированной архитектуры тогда, в 1995 г., оставалось еще десятилетие напряженной работы.
Тяжелая судьба PhoturisКонструкция управления ключами, созданная Карном для Photuris, в целом удовлетворяла головоломным требованиям IP-sec. Карн использовал механизмы защиты от атак DоS, впервые применил механизм проверки того, что партнер по соединению «жив» и не подменен другим, пустил по миру обозначающее этот механизм словечко cookie. Его идеи унаследованы многими современными криптопротоколами.
Из протокола 32-й сессии IETF, 1995 г.:
«Базовым документом [проектом протокола управления ключами] рабочей группы IPsec является Photuris».
Первая версия Photuris появилась в декабре 1994 г. Карн практически сразу же написал кодовый прототип и интенсивно развивал его больше года. А потом что-то сломалось... С начала 1996 г. имя Карна практически навсегда исчезло из переписки на тему Photuris. Почему? Неизвестно, но очевидно, что не обошлось без личного разочарования. Как бы то ни было, уход Карна стал явной потерей для РГ.
Жук в муравейникеВ РГ IPsec работали и дизайнеры коммуникационных протоколов, и криптографы - люди с очень разным образованием, стилем мышления и анализа. Блестящим представителем криптографов был Хьюго Кравчик. Он регулярно участвовал в дискуссиях РГ IPsec и непосредственно работал над ее стандартами. Свою роль Кравчик видел в анализе предлагаемых решений с позиций теоретической криптографии, и криптостойкость современных протоколов IPsec - во многом его заслуга. Зачастую, казалось бы, безупречное решение не выдерживает критики с точки зрения криптоанализа, и Кравчик терпеливо разъяснял коммуникационщикам изъяны предлагаемых ими вариантов.
Одна из сложностей состояла в том, что период разработки стандартов IPsec совпал с бурным прогрессом криптоанализа (в частности, анализа хэш-функций). На глазах рушились «безупречные» канонические схемы. Кравчик был вынужден на лету менять предложения, что воспринималось дизайнерами протоколов как непоследовательность, вызывало раздражение. Однако Хьюго умел преодолевать такие барьеры и заслужил авторитет у коммуникационщиков.
С именем Кравчика связана курьезная история. В середине 1998 г., когда разработка стандарта управления ключами IKE уже выходила на финишную прямую, в кулуарах очередной конференции IETF поползли слухи о «проблеме Теро». Добродушный бородатый финн Теро Кивинен, в котором сочетались талант программиста-практика и критический подход аналитика, увидел ошибку в многократно проверенном стандарте: из-за опечатки подписывался «не тот» блок данных. Виновник опечатки до сих пор не определен, но есть два кандидата на эту роль - автор IKE Дэн Харкинс и консультант IKE в области криптографии Хьюго Кравчик. Через год Кравчик косвенно признал свою вину, упомянув об unfortunate typo. Забавно, однако: его авторитет как криптографа был настолько высок, что до Кивинена опечатка не воспринималась как таковая. Если ее кто и обнаруживал, то считал, что так и надо.
Однако с опечаткой нужно было что-то делать. Изменение спецификации означало годовую потерю темпа (в IETF принят определенный жизненный цикл документа, и все фазы в нем обязательны) и миллионные убытки производителей, которые активно отлаживали свои продукты. К счастью, анализ показал, что «проблема Теро» не является катастрофической: неподписанные параметры так или иначе подтверждаются в процессе работы протокола. После дебатов рабочая группа сочла ошибку приемлемой и решила оставить все как есть. Так и фигурирует эта ошибка в спецификации IKE как памятник личному авторитету Хьюго Кравчика.
Слон в посудной лавкеБилл Симпсон появился в рабочей группе в 1994 г. Он живо включился в диалог об управлении ключами, внес весьма существенный вклад в разработку архитектуры IPsec, был членом многих групп IETF, соавтором стандартов Photuris, IPsec, PPP и RADIUS. Симпсон активно вел дискуссии, хорошо знал предмет, но в запале мог прибегнуть к демагогическим аргументам, был саркастичен и дерзок, использовал человеческие слабости и не прощал чужих ошибок.
Наиболее жесткое противостояние сложилось между ним и Кравчиком. Симпсон вообще питал уважение к практикам и недолюбливал теоретиков. Когда Кравчик, следуя достижениям криптоанализа и действуя вполне добросовестно, был вынужден менять свою позицию, Симпсон издевался: мол, полгода назад я уже пошел ему навстречу и переделал протокол, ан нет, уже опять все не так... Закончив дискуссию о технике, Билл мог добавить:
«...Я потратил более 3 часов... отвечая на это письмо. У меня масса дел, например работа над спецификациями или кодом... Поэтому я отказываюсь тратить время на этого типа [Кравчика]».
Впрочем, Симпсон «доставал» не только Кравчика. Его сарказм и скандальность в конце концов вывели из себя сопредседателя РГ Пола Ламберта. Тот написал открытое письмо, красноречиво поименованное «Цензура на г-на Симпсона» (февраль 1996 г.):
«Г-н Симпсон, ...Ваше поведение неприемлемо... Вы громко декларируете восприятие рабочей группой присланных Вами документов, но задеваете, оскорбляете и игнорируете тех, кто комментирует эти документы... Протокол Photuris был разработан Филом Карном... Вы заявили, что являетесь автором, а не редактором спецификации Photuris. В этом контексте Вы пугали... IETF судебным преследованием в том случае, если будете «устранены»... Как председатель, я хотел бы «изгнать» Вас из списка рассылки и убежден, что мою позицию одобрило бы подавляющее большинство РГ».
Мы подробно остановились на этом скандальном эпизоде потому, что скандальность Симпсона оказала непосредственное влияние на содержание протоколов, которыми сегодня пользуется весь мир. Но вот еще что интересно. Раньше мы видели, как IETF отверг «торговлю в храме», т.е. патентные интриги. Здесь - другой пример нравов этого сообщества. Тон письма Ламберта шокировал многих членов рабочей группы, не питавших к Симпсону симпатий, но не приемлющих административного давления. И среди ответов на письмо Ламберта преобладал протест именно против цензуры.
ТУРНИР
Гибель Photuris'а
К 1996 г. разработка протокола управления ключами зашла в тупик. Photuris казался наиболее естественным кандидатом на эту роль, но стиль работы Симпсона, который после ухода Карна взял проект на себя, вызывал блокировку процесса. Имея собственные взгляды на цели и задачи IPsec, Симпсон всячески противился внесению изменений, которые он не считал нужными.
В ноябре 1996 г. Аткинсон отчаялся убедить Симпсона внести ряд изменений в проект Photuris и, сославшись на свой статус сопредседателя РГ, прибег к прямому указанию изменить текст стандарта. Симпсон публично отказался, объяснив это техническими причинами. Поняв, что ситуация окончательно вышла из-под контроля, сопредседатели рабочей группы решили вытеснить Симпсона с позиции ключевого редактора. Но в таком случае надо было заново переписать все документы, которые он редактировал.
Именно тогда с единственной целью сделать процесс независимым от Симпсона сопредседатели РГ вывели в центр арены «темную лошадку» ISAKMP. И хотя Photuris был, по всем отзывам, многообещающим, этот протокол умер. Думается, для его гибели хватило и намека на то, что Photuris не станет стандартом: увидев такую перспективу, производители не рискнули тратить деньги на внедрение.
Баталии вокруг SKIPПозиции протокола SKIP казались куда более сильными: он был прост, функционален и довольно активно внедрялся. Однако SKIP не умел многого из того, что рабочая группа требовала от протокола управления ключами, и его доработки были неизбежны. Команда Sun пыталась выстоять под напором критики и постоянно совершенствовала свое детище, но это вело к усложнению протокола. Спор в стиле «вот дыра, а вот и заплатка» грозил стать бесконечным.
Когда спор инженеров заходит в тупик, включаются в дело исполнительные органы. Директор направления защиты информации (Security Area) IETF Джеффри Шиллер был вынужден взять принятие решения на себя. Он постановил развивать как ISAKMP/Oakley, так и SKIP, причем сделать первые два протокола обязательными, а третий - рекомендуемым.
После этого судьба протокола SKIP, как ранее и Photuris'а, была предрешена. Ведущие игроки переключились на обязательный протокол и не стали тратить лишних усилий на рекомендуемый.
ISAKMP: Deus ex machinaПротокол ISAKMP поначалу тускло выглядел на фоне конкурентов. Он был сырым, да и позиционировали его исключительно как «полуфабрикат», на основе которого следует разрабатывать реальные протоколы управления ключами. Из-за попытки охватить в нем все возможные случаи ISAKMP был явно перегружен опциями. Немало времени потребовалось, чтобы довести его до ума и наполнить рамочные формы подходящим содержанием.
Наполнением, связанным с обменом ключами, занялась Хилари Орман, которую косвенно «назначил на должность» вездесущий Симпсон: сопредседатели обратили на нее внимание как на альтернативного редактора именно после конфликта с Симпсоном. В определенном смысле Хилари была противоположностью Симпсона: тот безобразничал, а она - увещевала. В мужской казарменной обстановке группы IPsec при упоминании о Хилари «господа офицеры» как-то подтягивались, их тон заметно теплел, а поведение становилось более предупредительным.
Благодаря Орман в рамку ISAKMP был вписан протокол управления ключами Oakley, но и он «не опускался» до деталей реализации. Требовался еще один документ - сводящий все воедино. Первоначально он так и назывался The resolution of ISAKMP with Oakley, но впоследствии получил имя IKE (Internet Key Exchange). Как принято в IETF, это название имеет еще и «подтекст»: Ike - детское прозвище Эйзенхауэра.
Основной вклад в разработку IKE внес Дэн Харкинс. В тесном контакте с Хьюго Кравчиком он сумел в доступной для разработчиков форме свести в едином документе все необходимое для реализации протокола. Харкинс (как ранее Карн и Аткинсон, а впоследствии Кивинен) лично прототипировал написанное на бумаге. Он также участвовал в создании первой открытой справочной реализации протокола, выпущенной Cisco Systems.
РАБОТА НАД ОШИБКАМИНаконец в 1998 г. был принят полнофункциональный пакет стандартов IPsec. Но, как известно, недостатки теории лучше всего познаются на практике. По этому поводу уместно процитировать анекдот «из технологических источников»: «Инженер, химик и разработчик стандартов попадают на необитаемый остров и находят банку консервов. Инженер: «Приняв во внимание прочность материала банки, можно рассчитать силу броска банки о камень, чтобы она лопнула по шву, а содержимое не вылилось». Химик: «С учетом свойств материала банки можно рассчитать время ее выдержки в соленой воде, чтобы коррозия разрушила банку, не затронув содержимого». Разработчик стандартов, глядя вдаль: «Предположим, у нас есть консервный нож...».
На практике сразу выявилось, что (оказывается!) есть трудности с внедрением PKI и что в реальных сетях IPадреса меняют не только злоумышленники. К тому же пользователи встретили сопротивлением сертификаты как основной способ аутентификации: для их применения требовались дополнительные вложения в инфраструктуру, на что многие идти не хотели, предпочитая жертвовать безопасностью в пользу удобства и дешевизны. Такие компании, как Cisco Systems и Check Point, не желая терять корпоративных клиентов, стали предлагать собственные решения, которые позволяли адаптировать IKE к аутентификации по паролю пользователя. Эти расширения (XAUTH, Hybrid IKE) так и не вошли в стандарт, но стали стандартами де-факто.
Еще одной «неожиданной», как приход зимы, проблемой оказалось противоречие между IPsec и NAT (Network Address Translation). Во времена зарождения IPsec проблема нехватки IP-адресов не стояла столь же остро, как сегодня. Кроме того, все ждали скорого пришествия IPv6, призванного решить ее навсегда. Технология NAT казалась скорее экзотикой и не воспринималась всерьез. Но она быстро развивалась, и к моменту появления первых коммерческих IPsec-продуктов маршрутизаторы со встроенной NAT буквально наводнили рынок. И тут выяснилось, что протоколы AH и ESP не умеют «ходить» через NAT. Тогда РГ IPsec и производители маршрутизаторов с NAT начали решать проблему каждый со своей стороны.
Основной идеей разработчиков стала инкапсуляция AH и ESP в протокол IKE, который базируется на транспорте UDP, а потому не имеет проблем с NAT. Инкапсулированные AH и ESP опознавались по полю заголовка IKE, которое не могло быть нулевым, но приравнивалось к нулю при инкапсуляции. Казалось бы, решение найдено... Однако производители базировались на эмпирических представлениях, в соответствии с которыми поля AH и ESP могли обрабатываться в том виде, в каком они фигурировали в протоколе. Частью решения стал углубленный анализ полей протокола IKE, но «умные» маршрутизаторы, видя нулевое поле, которое по стандарту не должно быть таковым, не пропускали соответствующие пакеты. Так независимые усилия привели к взаимной блокировке полученных решений.
Круг замкнулся, и рабочей группе пришлось все начинать заново. В результате инкапсуляция AH и ESP в IKE осталась, но ее механизм был изменен так, чтобы удавалось «обманывать» NAT-маршрутизаторы. При этом протокол оказался переусложненным, что отрицательно сказалось на его надежности.
ВТОРАЯ СЕРИЯ: IKEv2Группа стандартов IPsec 1998 г. еще не была принята, когда посыпались замечания и предложения о создании новой версии протокола управления ключами. Им даже дали по IETF-овски меткие названия The son of IKE и IPsecond. В 1998 г., после выхода стандартов, было решено продолжить работу над ними и не распускать рабочую группу. Основными ее задачами провозглашались:
- упрощение протокола IKE;
- устранение избыточной и редко используемой функциональности;
- сведение спецификаций протокола управления ключами (IKE, ISAKMP) в один документ;
- включение в основной протокол востребованных расширений (парольные режимы аутентификации, сосуществование с NAT и т.п.);
- повышение уровня надежности протокола и скорости его работы;
- исправление ошибок.
Требований оказалось много, и назвать их простыми было нельзя. Ревизия затянулась на 7 лет (до 2005 г.) и закончилась появлением протокола IKEv2, который напоминал предшественника только названием. От старого IKE осталась только «рамка» ISAKMP, но и она прекратила существование как отдельный документ. В тот период в РГ царила благоприятная атмосфера, что способствовало плодотворной работе над стандартом. Основной вклад в создание IKEv2 внесли Чарли Кауфман, Теро Кивинен, Паси Эронен и Хьюго Кравчик, которые, по сути, дали индустрии протокол all-in-one, содержащий все необходимое для управления ключами сетевой защиты.
Но внедренческая история IKEv2 оказалась совершенно не похожей на судьбу ажиотажно внедрявшегося IKEv1. Несмотря на все проблемы и недоработки, IKEv1 был настолько востребован на рынке, что его реализации появились еще до принятия стандарта. А переходить на прогрессивный IKEv2 индустрия не спешит до сих пор.
Адрес: 105082, Россия, г. Москва, 2-й Ирининский пер, д. 3