Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

Более тридцати RFC детально рассматривают различные варианты, предоставляющие специальные возможности для telnet. Среди них можно выделить:

■ Способность опрашивать партнера о текущем состоянии параметров. Запрос и ответ о состоянии партнера переносятся при дополнительном согласовании.

■ Согласование размера окна. Партнеры соглашаются, что клиент может дополнительно согласовать высоту и ширину окна, которое будет использоваться в сеансе telnet . Эта возможность особенно полезна для запуска сеанса telnet в системах с многооконным интерфейсом.

Реализациям не требуется поддерживать все или многие из определенных в стандартах вариантов. Два из них, используемые при эмуляции терминала 3270, имеют специальные возможности:

■ Transmit Binary (пересылка двоичных данных). Начало отправки 8-разрядных двоичных данных (сеансы с терминалом IBM 3270 проводятся в двоичном режиме).

■ End of Record (конец записи). После получения DO END-OF-RECORD партнер использует стандартные управляющие коды IAC 239 для маркировки конца записи в общем потоке данных.

Вспомним, что даже после перехода в двоичный режим партнеру можно послать команды telnet , удваивая esc-символы IAC.

С точки зрения пользователей, желающих получить доступ к приложениям через эмуляцию терминалов ASCII или IBM, наиболее важным является способность telnet выполнять согласование и эмуляцию. Но разработчикам прикладного программного обеспечения основанный на NVT telnet предлагает достаточно бедный набор средств для реализации функций клиент/сервер, которые трудно и утомительно воспроизводить в программах. Мы уже знаем, что базовыми возможностями NVT являются:

■ Проверка активности равного приложения

■ Сигнализация прерывания

■ Запрос на прерывание удаленного текущего процесса

■ Использование сигнала синхронизации для указания равному приложению на отбрасывание всех данных, кроме команд telnet

■ Указание партнеру на отмену ожидаемой пересылки данных из буфера

Сегодня в локальных сетях повсеместно используются широковещательные рассылки. Многие организации используют их даже в магистральных сетях FDDI.

Пользователям PC или Macintosh очень легко найти программное обеспечение для превращения настольной системы в шпиона, который может подслушивать трафик локальной сети. Такие средства имеют многие станции Unix, владельцам которых нужно только разрешить их использование.

Традиционно пользователь доказывает свои права, посылая хосту секретный пароль. Но в локальной сети с широковещательной рассылкой передача идентификатора и пароля по сети не обеспечивает для них никакой защиты. Любой может подслушать эти сведения.

Не помогает и шифрование пароля. Взломщику даже не нужно будет расшифровывать пароль, а потребуется только переслать его в том же виде и таким путем получить доступ к чужим регистрационным данным. Все это свидетельствует о необходимости безопасного механизма аутентификации (установление подлинности).

В telnet реализована аутентификация , позволяющая партнерам согласовать один из вариантов этого механизма. Последовательность действий следующая:

■ Сервер посылает DO AUTHENTICATION

■ Клиент отвечает WILL AUTHENTICATION

С этого момента вся информация будет пересылаться в сообщениях дополнительного согласования.

■ Сервер посылает сообщение, содержащее список пар аутентификации. Каждая пара включает тип аутентификации (который нужно использовать) и модификатор, обеспечивающий дополнительную информацию (например, сведения об аутентификации будут посылаться только клиентом или одновременно — клиентом и сервером).

■ Клиент отправляет простой идентификатор пользователя (userid) или идентификатор регистрации.

■ Клиент выбирает из списка одну из пар аутентификации и посылает сообщение, идентифицирующее тип аутентификации, включая аутентификационные данные. В зависимости от протокола может потребоваться более одного сообщения.

■ Сервер принимает аутентификацию.

■ Если выбрана взаимная аутентификация, клиент запрашивает от сервера его аутентификационные данные.

■ Сервер отвечает, сообщая свои аутентификационные данные.

Типы аутентификации зарегистрированы в IANA и имеют числовые коды. Текущее соответствие между кодами и типами таково: