4. Архитектура
4.1. Ключи хостов
Каждому серверному хосту следует иметь ключ (host key). Хосты могут иметь множество ключей, созданных с использованием различных алгоритмов. Возможно использование одного ключа множеством хостов. Если хост имеет ключи, он должен обеспечивать по крайней мере один ключ, который использует каждый из требуемых алгоритмов открытых ключей (DSS [FIPS-186-2]).
Ключ сервера используется в процессе обмена ключами для подтверждения того, что клиент реально связывается с нужным сервером. Для того, чтобы такая проверка стала возможной, клиент должен заранее знать открытый ключ сервера.
Могут использоваться две модели поддержки ключей:
- Клиент поддерживает локальную базу данных, в которой содержатся имена всех хостов (указанные пользователем) и соответствующие открытые ключи. Этот метод не требует создания инфраструктуры централизованного управления или сторонней координации. Недостатком данного метода является трудоемкость поддержки ассоциаций между ключами и именами хостов.
- Ассоциации между ключами и хостами сертифицируются специальным агентством CA (Certification Authority). Клиент знает только ключ корневого CA и может проверить все ключи хостов, сертифицированные приемлемыми агентствами CA.
Второй вариант упрощает задачу поддержки, поскольку клиенту нужно хранить единственный ключ CA. С другой стороны, в этом варианте требуется централизованная сертификация каждого хоста прежде, чем станет возможной процедура проверки полномочий. Кроме того требуется обеспечить высокий уровень для централизованной инфраструктуры сертификации.
Протокол позволяет отключить проверку ассоциации «сервер — ключ» при первом подключении к хосту. Это позволяет организовать соединение с хостом до получения от него ключа или сертификации хоста. При таком соединении обеспечивается защита от пассивного прослушивания, но существует уязвимость для активного перехвата с участием человека. Реализациям в общем случае не следует разрешать такие соединения по умолчанию, поскольку они могут снижать уровень безопасности. Однако по причине отсутствия в сети Internet широко доступной структуры обмена ключами на момент написания документа эта опция может оказаться весьма полезной в переходный период, пока такая инфраструктура не будет создана, и обеспечит значительно более высокий уровень безопасности, нежели более старые решения (например, telnet [RFC0854] и rlogin [RFC1282]).
Реализациям протокола следует предпринимать разумные меры по проверке ключей хостов. Примером возможной стратегии может служить принятие ключа без проверки только при первом соединении с хостом, сохранение полученного ключа в локальной базе данных и его использование при каждом последующем подключении к данному хосту.
Реализации могут обеспечивать дополнительные возможности по проверке корректности ключей хостов (например, использование шестнадцатеричных «отпечатков», полученных хэша открытого ключа с помощью алгоритма SHA-1 [FIPS-180-2]). Такие «отпечатки» можно легко проверить по телефону или с использованием другого коммуникационного канала.
Всем реализациям следует обеспечивать опцию для запрета принятия непроверенных ключей хостов.
Члены рабочей группы полагают, что простота использования играет важную роль при выборе безопасных решений конечными пользователями и уровень безопасности не станет выше, если не будут применяться новые решения. Таким образом можно предполагать, что обеспечение опции, позволяющей отказаться от проверки ключа, будет повышать общий уровень безопасности в сети Internet, несмотря на локальное снижение уровня безопасности протокола в тех случаях, когда проверка отключена.