Аутентификация идентификатора пользователя

 

В работе [54] приводятся данные ассоциации по контролю за мошенничеством CFCA (Communication Fraud Control Association), направленным на использование услуг связи без их оплаты, т.е. за фродом. Согласно этим данным в результате фрода ежегодные потери для операторов традиционных сетей связи составляют 3-5% от доходов оператора и величина таких потерь ежегодно увеличивается на 10%. По результатам анализа этой организации следует, что угрозы фрода и потери операторов в сетях VoIP выше.

Cхема HTTP Digest Authentication остается наиболее используемым механизмом аутентификации в SIP, но ей свойственны некоторые слабости в защите от угроз. Многие исследования в этом отношении связывают с протоколом хеширования MD5. Другая проблема слабости этой схемы как отмечено в документе RFC 4474, связана с необходимостью организации установления паролей у аутентификатора и пользователя. Для создания хеш-кода MD5 необходим ввод открытого текста пароля. В базе данных хранятся хеш-коды MD5 пароля, имя пользователя (username) и доменное имя (realm). Для того чтобы риски безопасности были удовлетворительными, необходимо эти данные хорошо защитить.

Даже при успешном решении всех этих задач остается проблема защиты от фальсификации и других манипуляций с идентификатором From, расположенным в поле заголовка запроса SIP. В идентификаторе содержится адрес URI отправителя запроса. При этом рассматриваются следующие угрозы ИБ и последствия при их реализации:

• кража идентификатора другим пользователем-нарушителем, который начинает пользоваться всеми услугами легитимного пользователя. В результате он получает доступ к определенным услугам;
• кража подписки. В результате такой кражи идентификатора, при которой нарушитель получает вызовы, предназначенные для легитимных пользователей;
• приватность. Вызываемый пользователь хотел бы иметь некоторую гарантию того, что вызывающий пользователь тот, за которого себя выдает. Вызывающий пользователь часто желает спрятать свой идентификатор от вызываемого пользователя и не доверенного провайдера услуг. Для того чтобы обеспечить приватность вызывающего пользователя информация его идентификатора должна быть скрыта таким же образом, как зашифровывается информация от не доверенных провайдеров услуг. При этом необходимо также обеспечить возможность маршрутизации. Кроме этого требуется обеспечить возможность предоставления счетов за предоставленные пользователям услуги связи. Поэтому должен быть использован механизм обеспечения ИБ из конца в конец.

Протокол RFC 3261 не определяет механизм защиты от угроз идентификатору. Самым надежным решением является использование пользователями аутентификации с помощью сертификатов, что представляет практические трудности реализации. Поэтому протокол RFC 4474 [60] предлагает в качестве промежуточного более простой вариант, основанный на концепции «сервис аутентификации» и введении нового заголовка SIP – Идентификатор. Для того чтобы пояснить принятый алгоритм аутентификации идентификатора RFC 4474 приведем пример реализации: Алис желает установить сеанс с Бобом. sip:[e-mail]; sip:[e-mail].

Алис отправляет запрос INVITE с полем заголовка From, который используя протокол TLS поступает на прокси-сервер, выполняющий функцию сервиса аутентификации ее домена. Сервис аутентификации аутентифицирует Алис (возможно отправляя вызов HTTP Digest Authentication) и подтверждает подлинность идентификатора в поле заголовка From. Прокси-сервер, выполняющий функцию сервиса аутентификации, определяет хеш-функцию данных, включающих поле заголовка From и тело заголовка, подписывает закрытым ключом сертификата домена (в данном случае домена example.com) и вставляет его в новое поле заголовка - Идентификатор. Прокси-сервер, выполняющий функцию сервиса аутентификации домена, в котором расположен Боб, расшифровывает эту подпись и убеждается в аутентификации источника, в подлинности идентификатора в поле заголовка From. Та же самая проверка подлинности может быть выполнена сервером агента пользователя UAS.