Идентифиакция пользователей в SIP


Выдержка из RFC 3261

Протокол SIP предоставляет статусонезависимый, основанной на технологии двухстороннего обмена, механизм для авторизации, который используется в протоколе HTTP. В любое время, когда прокси сервер или клиент (UA) принимает запрос (за исключением тех, что описаны в Разделе 22.1), он МОЖЕТ запросить у инициатора этого запроса гарантию подлинности его идентификации. Когда инициатор уже был идентифицирован, сторона, принимающая запрос, ДОЛЖНА убедиться может или нет, для этого авторизированного пользователя, быть выполнены действия указанные в запросе. В этом документе нет рекомендаций или обсуждений самих систем для авторизации.

Digest авторизация, описанная в этом разделе, предоставляет только механизм идентификации сообщений и защиту от повторного использования перехваченных данных авторизации, без модификации самого сообщения и не обеспечивая конфиденциальность данных сообщения. До и после идентификации, с помощью этого механизма Digest авторизации, должны быть предприняты дополнительные мероприятия по защите от действий по модификации содержания SIP запросов и ответов, которые могут предприняты атакующей стороной.

Обратите внимание, что из-за слабой защищенности, использование "Базовой" (Basic) схемы авторизации (где логин и пароль передаются по каналам связи незашифрованными) объявлено нежелательным. Все Сервера НЕ ДОЛЖНЫ подтверждать полномочия клиента, если используется "базовая" схема авторизации и НЕ ДОЛЖНЫ как-либо реагировать на запросы, которые используют эту схему авторизации. Эти изменения описаны в RFC 2543.

Что такое "realm"?


Вообще, прохождение авторизации в SIP протоколе зависит от "realm", различного для каждого защищаемого домена. Таким образом, в Digest авторизации, каждый защищаемый домен имеет свой набор имен пользователей и паролей.
Цитата из RFC2617:

REALM:
Это строка, отправляемая пользователю, который, собственно, знает какое имя пользователя и пароль следует использовать. Эта строка должна содержать, как минимум, имя хоста, производящего авторизацию, и может дополнительно содержать имя списка пользователей, которые могут иметь доступ. Например, эта строка может выглядеть так: "registered_users@gotham.news.com".


Какая авторизация должна использоваться: WWW или proxy-auth?

  • Когда производиться авторизация на сервере, который предоставляет сервис, должен использоваться заголовок "www-authentication".
  • Когда производиться авторизация на сервере, который проксирует запросы до места их назначения, должна использоваться proxy-authentication.
  • В _одной_ транзакции, могут одновременно использоваться www_authentication и proxy_authentication

Коды ответа при ошибке авторизации - 401 или 407?

Если сервер, проверяющий авторизацию, не может принять авторизационные данные, переданные в запросе, то он ДОЛЖЕН ответить сообщением с кодом 401 (Unauthorized). Ответ ДОЛЖЕН включать в себя заголовочное поле: "WWW-Authenticate", содержащее, как минимум одну (и по возможности, заново сгенерированную) строку для проведения авторизации, пригодную к использованию запрашивающим клиентом. Если прокси сервер, проверяющий авторизацию, не может принять авторизационные данные, переданные в запросе, то он ДОЛЖЕН ответить сообщением с кодом 407 (Proxy Authentication Required). Ответ ДОЛЖЕН включать в себя заголовочное поле: "Proxy-Authenticate", содержащее, как минимум одну (и по возможности, заново сгенерированную) строку для проведения авторизации на прокси сервере, пригодную к использованию запрашивающим клиентом.


Авторизация для сообщений ACK и CANCEL


В этой схеме авторизации, когда используются полученные значения от сервера для генерации случайной строки, которая и будет отправлена серверу (Digest) для проверки авторизации, существуют некоторые проблемы, связанные с использованием запросов, которые не требуют ответных сообщений, например, ACK. По это причине, любая авторизационная информация в сообщении INVITE, которая была подтверждена сервером, ДОЛЖНА всегда признаваться сервером валидной и для сообщений ACK.
Пользовательские агенты (UAC) при создании сообщения ACK должны продублировать все значения заголовочных полей "Authorization" и "Proxy-Authorization", значениями из INVITE, в соответствующем сообщении ACK. Сервера НЕ ДОЛЖНЫ пытаться произвести проверку авторизации в сообщениях ACK.
Несмотря на то, что при использовании метода CANCEL, мы в ответ получаем сообщение с кодами (2xx), сервера НЕ ДОЛЖНЫ пытаться произвести проверку авторизации, используя запрос CANCEL, по той причине, что эти запросы не должны повторно перепосылаться. Вообщем, запрос CANCEL ДОЛЖЕН всегда подтверждаться сервером, если он поступил с того же узла, что и запрос, который он отменяет.


Итак, суммируя все сказанное:
  • Для авторизации в SIP протоколе достаточно имени пользователя и realm для авторизации.
  • Сервер запраишвает данные пользователя, отправляя ему значения "realm" и "nonce".
  • Если у абонента имеется имя пользователя для авторизации в рамках полученного realm, то он вычисляет ответ основываясь на всех авторизационных данных, включая поле "пароля".
  • Имя пользователя, используемое для авторизации -это не тоже самое, что имя пользователя в SIP протоколе.
  • Realm используемый для авторизации - не тоже самое, что и SIP домен.
  • Многие пользовательские SIP агенты (UA) имеют неправильную реализацию алгоритма, где Вы не можете установить имя пользователя и realm для авторизации.

  • Наилучшее решение для агентов пользователей - это существование одной настройки для каждого домена плюс имени пользователя для SIP, и набор настроек для авторизации, в зависимости от разных значений realm.
  • На сегодняшний день, во многих клиентах существует ограничение, которое заключается в том, что одна и та же связка имения пользователя/пароля используется для всех realm, это не очень хороший путь в отношении обеспечения нормального уровня безопасности.

Digest авторизация в протоколе HTTP

Алгоритм работы HTTP Digest авторизации описан в документе: RFC2617 и расширен в документе RFC 3310.