18.2.3.4. Механизм аутентификации пользователя в sip-сети на базе протокола http Digest

Протокол HTTP используется в Интернете при обмене документами между веб-клиентами и серверами. В простейшем случае агент пользователя устанавливает прямое соединение с сервером, на котором расположен нужный пользователю ресурс [30]. Примером может служить интернет-сервер, на котором размещается нужная страница. В таком примере между клиентом и сервером создается TCP соединение. Затем клиент делает HTTP-запрос, который состоит из специфической команды, адреса URL (Uniform Resource Locator, унифицированный указатель информационного ресурса) и сообщения в формате MIME, содержащего параметры запроса, информацию о клиенте и другую информацию. Когда сервер получает запрос, он пытается выполнить его, а затем возвращает HTTP-ответ в формате MIME. Возможны между клиентом и сервером обработки запроса пользователя одна или более промежуточных систем, через которые транслируется запрос и ответ от сервера. В сетях HTTP в качестве промежуточных систем могут быть прокси-серверы, шлюзы, туннели и др.

Ответственность сервера SIP возложена на все три процедуры информационной безопасности – аутентификация, авторизация и учет, обычно обозначающим триединым термином AAA (Authentication, Authorization, Accounting). Все три процедуры связаны между собой. Например, учет использования ресурса для выставления счета имеет смысл, источник соединения подлинный, то есть аутентифицирован. После успешной аутентификации (authentication) следует определить на каких условиях (параметры качества обслуживания, виды услуг и др.) ему может быть предоставлен доступ. Эта процедура относится к авторизации (authorization). Выставление счетов за услуги основывается на длительности соединения и потребленных при этом ресурсах. Сбор такого рода информации осуществляется в рамках процедур учета (accounting). Все три функции ААА могут быть вставлены в SIP сервер или быть во внешнем сервере. Если используется внешний сервер, то он выполняет функции протокола RADIUS. Название протокола складывается из первых букв слов – Remote Authentication Dial in User Service (услуга удаленной аутентификации вызывающего пользователя). Это определение не точно, так как описывает только одну (хотя и чаще всего применяемую) процедуру из ААА – аутентификацию пользователя для получения доступа к сети.

Для обеспечения аутентификации в сети SIP может быть положен в основу принцип аутентификации для протокола HTTP, стандартизированный в документе RFC 2617 [59].

Определение подлинности источника запроса (аутентификация) важно по следующим причинам: пользователи должны знать с кем они разговаривают; операторы услуг должны знать кто должен платить за разговор и кому они должны предоставить приоритет. Защита от спама ничего не стоит, если ненадежное обеспечение аутентификации.

Основной механизм, используемый для определения подлинности источника SIP запроса, является схема «Digest», которая базируется на принципах аутентификации для протокола HTTP (HTTP Digest Authentication). Она основана на общем пароле в сервере и у клиента. Этот протокол «вызов-ответ» использует хеш-код MD5 (128 бит) пароля пользователя, который по открытому каналу в адрес сервера передает измененный пароль. Сервер может проверить поступивший хешированный пароль, но перехвативший его злоумышленник не может по нему восстановить пароль. Хеш-функция формируется из пароля и дополнительных нескольких значений. Для того чтобы защититься от угрозы повтора перехваченного злоумышленником хеш-кода и повторно отправленного им в адрес сервера, хеш-код включает ранее полученное со стороны сервера случайное число (нонс). В результате хеш-код становится не постоянной величиной. Хеш-код включает также несколько значений самого SIP сообщения. Сервер проверяет полученный вызов. Для этого он рассчитывает собственный хеш-код, сравнивает его с принятым от клиента. Если они совпадают, то сервер убеждается в подлинности клиента. В качестве сервера при использовании такого механизма аутентификации может быть прокси-сервер или сервер регистрации.

Предусмотрено использование механизма аутентификации на базе схемы «Digest» в следующих процедурах:

• пользователь-пользователь. При этом производится аутентификация между UAC и UAS. UAS может быть, например, вызываемым пользователем или сервером регистрации SIP. В первом случае аутентификация имеет место при запросе вызова, во втором – во время регистрации;

• пользователь-прокси. При этом производится аутентификация между UAC и прокси-сервером SIP при запросе вызова.

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

Приведем последовательность шагов примера аутентификации пользователь-пользователь в случае сервера регистрации. Она включает обмен четырьмя сообщениями.

1. Начальный запрос. Агент UAC отправляет запрос в сервер (например, в сервер регистрации SIP) - INVITE sip:bob@biloxicom

2. Вызов (challenge). Сервер регистрации отправляет ответ – 401 Unauthorized (с кодом 401, не авторизирован), сообщение которого содержит заголовок WWW-Authentication, в котором следующие параметры:

• Realm – содержит имя хоста или доменное имя сервера, исполняющего аутентификацию и используется для того, чтобы спрятать пароль и имя пользователя – WWW-Authenticate: Digest realm=” biloxi.com” .

• Показатель качества защиты (qop) – может быть “auth” , “auth int” или не указан. В зависимости от этого показателя определяются схемы расчета ответа серверу, которые приводятся ниже в настоящем разделе.

• Nonce (нонс сервера, т.е. случайное число) – сгенерировано сервером и используется клиентом для расчета ответа. Нонс сервера состоит из штампа времени, связанного с хеш-кодом, рассчитанным по штампу времени и паролю сервера. Эта схема обеспечивает защиту от повтора, исходя из свежести нонса, который возвратится в заголовке Authorization (авторизация) последующих запросов: nonce=”dcd98b7102dd210e8b11ddf6ddbf0c093”

• Opaque – содержит данные, которые должны вернуться от агента UAC в заголовке Authorization (авторизация) последующего запроса. Сервер может использовать это поле для того, чтобы сохранить эту информацию, связанную с сеансом аутентификации: opaque= “5ccc069c4d3ebaf9fd17e95f4de41”

• Алгоритм – MD5 или MD5-sess. Эти алгоритмы отличаются между собой схемой расчета ответа агента UAC в адрес сервера.

3. Ответ (response). UAC рассчитывает ответ и передает серверу новый запрос. На этот раз заголовок этого запроса включает заголовок Authorization авторизации, который содержит следующие параметры.

• Имя пользователя – имя пользователя в realm: INVITE sip:bob@biloxicom, Authorization Digest username=”bob”

• Realm – то же, что в заголовке WWW-Authentication - realm=” biloxi.com”

• Nonce - то же, что в заголовке WWW-Authentication: nonce=”dcd98b7102dd210e8b11ddf6ddbf0c093”

• Digest URI (uri) – значение URI. Запрос URI может меняться при транзите: un= sip:bob@biloxicom

• Показатель качества защиты (qop) – указывает качество защиты, выбранное UAC: qop=auth,

• Счетчик нонса (nonce count, nc) – указывает на число различных запросов, отправленных UAC, использующих значение нонса в этом запросе. Счетчик нонса используется для защиты от угрозы повтора: n=00000001

• Если в заголовке имеется параметр показателя качества защиты gop, то в заголовке должен присутствовать параметр cnonce – нонс клиента: cnonce=”0a41113b”. Этот параметр (случайное число) генерирует клиент для расчета и проверки ответа. Это предусмотрено для защиты открытого пароля злоумышленником, представившимся сервером. Нонс клиента позволяет защищать от угрозы повтор за счет введения случайного характера в передаваемом сообщении.

• Ответ – рассчитанное агентом UAC значение ответ: response=”6629fae49393a05397450978507c4ef1”

• Opaque - то же, что в заголовке в сообщении 2 WWW-Authentication: opaque= “5ccc069c4d3ebaf9fd17e95f4de41”

• Алгоритм MD5 или MD5-sess - то же, что в заголовке WWW-Authentication.

Аутентификация пользователя считается успешной, если произведенный сервером расчет значения ответ по параметрам в заголовке WWW-Authentication совпадает с поступившим значением ответ от UAC.

Далее приводится описание, каким образом производится расчет значения ответ. Используются следующие понятия: KD(secret, data) = H(secret|| “||”||data), где H означает применение хеш-функции MD5 соответственно к входным параметрам и unq(param), которые обозначают значения параметров”param”, указанных в кавычках.

Когда качество защиты есть “auth” или “auth-int”, ответ рассчитывается следующим образом

ответ = KD (H(A1), unq(nonce) || “:”||unq(cnonce)|| “:”|| unq(gop)|| “:”|| H(A2)) (1.1)

В том случае, кода параметр gop отсутствует

ответ = KD (H(A1), unq(nonce) || “:”|| H(A2)) (1.2)

Когда используется алгоритм MD5 входящее в выражения 1.1 и 1.2 значение A1 рассчитывается по следующей формуле

A1= unq(username)|| “:”||unq(realm)||“:”||passwd. (1.3)

Здесь “passwd” означает пароль пользователя.

Когда используется алгоритм “MD5-sess”, значение A1 рассчитывается по следующей формуле

A1=H(unq(username)||“:”||unq(realm)||“:”||unq(passwd)||”:”|| (unq(nonce)|| “:”||unq(cnonce) (1.4)

Как видно из формул, ответ включает среди других параметров хеширование пароля. В тех случаях, когда используется отдельный север аутентификации, сервер SIP получает значение H(A1) из сервера аутентификации.

Когда качество защиты “auth” или не специфицировано, значение A2 определяется по формуле

A2=method||”:”||URI. (1.5)

Здесь “method” обозначает имя метода SIP. Если определено качество защиты “auth-int” специфицировано значение A2 определяется по формуле

A2=method||”:”||URI||”:”||H(bady). (1.6)

Здесь “bady” означает тело заголовка запроса SIP, целостность которого защищена с помощью хеширования. 4. Взаимная аутентификация. В том случае, если аутентификация пользователя завершилась успешно, выполняется процедура аутентификации сервера регистрации. При этом сервер отправляет ответ с кодом 200 (ОК), в сообщении которого содержится заголовок Authentication-Info, включающий следующие параметры.

• Nextnonce – генерирует еще один нонс (случайное число), которое UAC должен будет использовать для аутентификации сервера при следующем запросе;

• Показатель качества защиты (qop) – указывается качества защиты, которое обеспечивает сервером к сообщению ответа.

• Нонс клиента (cnonce) – то же, что обеспечивается клиентом сообщении 3 в заголовке авторизации Authrithation.

• Счетчик нонса (nonce count, nc) – копия счетчика нонса сервера в сообщении 3.

• Response authentication (rspauth) – рассчитанный сервером ответ для того, чтобы доказать, что он знает пароль пользователя. Для ответа сервера используются те же равенства, что и для ответа клиента (выражения 1.1 и 1.2). Исключение составляет определение A2.

Когда качество защиты принято “auth” или не специфицировано, A2 рассчитывается для ответа при аутентификации сервера по формуле

A2=”:”||URI.

Если качество защиты “auth-int”, то

A2=”:”||URI ||”:”||H(bady).

Здесь “bady” означает тело заголовка ответа SIP, целостность которого защищена с помощью хеширования.

Аутентификация сервера считается успешной, если произведенный UAC расчет значения ответ по параметрам в заголовке Authentication-Info совпадает с поступившим значение ответ от сервера.

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

Семантика заголовков Proxy-Authentication, Proxy-Authorization, Proxy-Authentication-Info подобна заголовкам WWW-Authentication, Authentication, Authentication-Info.

Процедура аутентификации состоит из следующих шагов.

Если запрос SIP не содержит заголовок Proxy-Authentication, то сервер отправляет ответ 407 (Аутентификация прокси-сервера обязательна). Приняв ответ 407, UAC использует параметры вызова (challenge) из этого заголовка и производит расчет ответа (response) аналогично тому, как это делается при аутентификации пользователь-пользователь и показано выше. Значение этого ответа включено в заголовок следующего запроса INVITE.

Прокси-сервер проверяет ответ UAC и может завершить аутентификацию пользователя. Прокси-сервер может также аутентифицировать себя пользователем UAC. При этом сервер отправляет ответ с кодом 200 (ОК), в сообщении которого содержится заголовок Proxy-Authentication-Info, включающий необходимые параметры. Эта процедура аналогична этапу взаимной аутентификации пользователь-пользователь.

Если следующий нонс установлен в заголовке Proxy-Authentication-Info, UAC сохраняет это значение, а также добавляет единицу в счетчик нонса (nonce count, nc) для того, проводить аутентификацию при следующих запросах.