Способы выполнения аутентификации для универсальной системы мобильной связи (усмс, umts) с использованием сообщений протокола инициирования сеансов (sip)

Способ аутентификации пользователя на сервере с использованием сообщений Протокола инициирования сеансов (SIP) заключается в том, что направляют запрос SIP от агента пользователя на сервер. Затем сервер направляет запрос на аутентификацию агенту пользователя в ответ на запрос-приглашение, причем запрос на аутентификацию включает в себя информацию о том, что аутентификация будет выполнена с использованием механизма соглашения об аутентификации и ключах (САК) для универсальной системы мобильной связи (УСМС), что и является достигаемым техническим результатом. Затем агент пользователя в соответствии с механизмом САК для УСМС направляет ответ об аутентификации на сервер, после чего сервер выполняет соответствующие действия для реализации вызываемой процедуры SIP в ответ на запрос SIP. Запрос SIP может включать в себя любой стандартизированный запрос SIP, содержащий либо запрос SIP INVITE (приглашение), либо запрос SIP REGISTER (регистрация). Запрос на аутентификацию может включать в себя либо код 401 SIP He разрешено, либо код 407 SIP Требование аутентификации у посредника. Запрос на аутентификацию должен содержать векторы случайного вызова RAND и маркера аутентификации AUTN процедуры САК для УСМС, которые могут быть включены в поле заголовка ответа WWW-аутентификации или аутентификации у посредника SIP. Ответ об аутентификации должен содержать либо код RES, либо код AUTS процедуры САК для УСМС или код ошибки. 2 н. и 14 з.п. ф-лы, 2 ил.

 

Область техники, к которой относится изобретение

Настоящее изобретение относится к способам выполнения аутентификации с использованием сообщений протокола инициирования сеансов (SIP). В частности, настоящее изобретение касается способов выполнения аутентификации для универсальной системы мобильной связи (УСМС, UMTS) с использованием сообщений SIP.

Уровень техники

Для системы R00 (Release 2000) в качестве протокола для интерфейса пользователь-сеть (ИПС, UNI), то есть интерфейса между мобильным абонентом и функцией управления состоянием вызова (ФУСВ, CSCF), был выбран протокол SIP, причем действующее Соглашение об аутентификации и ключах (САК, AKA) для УСМС является одним из предложений по механизму аутентификации для УСМС R00.

Протокол SIP определен в проекте стандарта RFC2543 (Запросы на комментарии), разработанного Проблемной группой проектирования Интернет (IETF) и опубликованного в марте 1999 года, при этом САК для УСМС определено в спецификации TS33.102, версия 3.5.0, Release 1999, Проекта сотрудничества 3-го поколения (3GPP), опубликованной в июле 2000 года. Содержание указанного проекта протокола в целом и содержание указанной спецификации в целом включены в данное описание.

В проекте протокола установлено следующее.

Протокол инициирования сеансов (SIP) является протоколом управления (сигнализации) прикладного уровня для создания, модификации и завершения сеансов с одним или несколькими участниками. Сеансы включают в себя конференции с использованием средств мультимедиа через Интернет, телефонные вызовы через Интернет и мультимедийное распространение информации. Участники сеанса могут осуществлять связь по многоадресной схеме, либо через объединение однонаправленных связей, либо используя их комбинацию.

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

Однако использование процедуры САК для УСМС для выполнения аутентификации посредством сообщений SIP в указанном проекте стандарта не раскрыто.

Кроме того, в подсистеме мультимедийных средств IP (Интернет-протокола) (IM), которая поддерживает мобильную IP-телефонную связь, механизм аутентификации абонента должен быть унифицирован. Такой механизм аутентификации пока не унифицирован. Однако скорее всего в качестве механизма аутентификации будет выбрана процедура САК для УСМС. Следовательно, необходимо определить способ выполнения САК для УСМС с использованием протокола SIP.

Сущность изобретения

Таким образом, задачей настоящего изобретения является создание способа выполнения аутентификации с использованием процедуры САК для УСМС и передачи соответствующих параметров УСМС посредством сообщений SIP. Аутентификация может быть выполнена либо путем создания нового режима аутентификации САК для УСМС с помощью соответствующих полей, содержащихся в сообщении SIP, либо, в альтернативном варианте, аутентификация может быть выполнена путем повторного использования и адаптации существующего режима аутентификации (например, «дайджестный» режим (digest mode) или режим PGP) сообщения SIP, где PGP (Pretty Good Privacy) - это набор алгоритмов высоконадежного шифрования («надежная конфиденциальность»).

Другой задачей настоящего изобретения в случае подсистемы IM является использование сообщений SIP, которые были выбраны для использования в качестве протокола управления вызовом между оборудованием пользователя (ОП, UE) и функцией ФУСВ, для переноса параметров аутентификации.

Еще одной задачей настоящего изобретения является повторное использование механизма САК для УСМС в качестве возможного решения для процедуры аутентификации в подсистеме IM.

Следующей задачей настоящего изобретения является определение того, какие сообщения SIP и поля заголовка следует использовать для переноса параметров аутентификации УСМС, для того чтобы применить механизм САК для УСМС для аутентификации абонента в подсистеме IM, и как включить параметры аутентификации УСМС в поля заголовка SIP.

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

На фиг.1 дан пример потока данных между агентом пользователя (АП, UA) SIP и функцией ФУСВ; фиг.2 - пример потока данных между АП SIP и функцией ФУСВ.

Наилучший вариант осуществления изобретения

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

На фиг.1 показан пример потока данных между АП SIP и функцией ФУСВ. Однако вместо ФУСВ может быть использован сервер-посредник. В соответствии со стратегией безопасности, когда необходимо выполнить процедуру САК для УСМС (например, при установке вызова или при регистрации), агент АП в ОП посылает запрос REGISTER (регистрация) или INVITE (приглашение) в ФУСВ или сервер-посредник. Функция ФУСВ или сервер-посредник может разрешить регистрацию, отправив сообщение OK 200, либо запросить проверку полномочий, послав ответ 401 Не разрешено.

Согласно вышеупомянутой спецификации 3GPP, чтобы выполнить процедуру САК для УСМС, пользователю должны быть посланы параметры для аутентификации, а именно RAND и AUTN, после чего пользователь должен дать ответ.

Таким образом, ответ 401 включает в себя поле заголовка ответа для WWW-аутентификации, которое содержит необходимую схему проверки полномочий и соответствующие параметры. При выполнении процедуры САК для УСМС согласно настоящему изобретению заголовок для WWW-аутентификации включает параметр случайного вызова (RAND) и параметр маркера аутентификации (AUTN).

Получив ответ 401, АП может послать новый запрос REGISTER или INVITE, который должен содержать в поле заголовка проверки полномочий соответствующую информацию для проверки полномочий. В случае процедуры САК для УСМС согласно настоящему изобретению заголовок проверки полномочий содержит параметры RES или AUTS либо код ошибки (например, может быть послано сообщение об ошибке, если код аутентификации сообщения (КАС, MAC) признан недействительным).

Обратимся теперь к фиг.2, где показана процедура аутентификации у посредника после представления запроса INVITE; при этом после направления запроса INVITE от АП на ФУСВ функция ФУСВ может запросить аутентификацию, послав ответ 407 с требованием аутентификации у посредника. Ответы 407 включают в себя поле заголовка для ответа об аутентификации у посредника, которое содержит необходимую схему проверки полномочий и соответствующие параметры.

После приема ответа 407 АП посылает ответ с подтверждением приема (ПП, ACK) и может повторить запрос INVITE, причем этот повторный запрос содержит соответствующую информацию для аутентификации в поле заголовка для проверки полномочий у посредника.

В случае процедуры САК для УСМС заголовок аутентификации у посредника содержит ту же информацию, что и заголовок WWW-аутентификации, а заголовок проверки полномочий у посредника содержит ту же информацию, что и заголовок проверки полномочий. Поскольку эту процедуру можно использовать только тогда, когда АП посылает запрос, например, когда он инициирует вызов, эта процедура не может заменить аутентификацию при регистрации.

Заметим, что запрос REGISTER, сообщение OK 200 и ответ 401 Не разрешено, а также другие параметры и элементы, упомянутые в вышеприведенном описании, точно определены в вышеупомянутом проекте стандарта RFC2543.

Вышеупомянутый проект стандарта определяет три различных способа аутентификации SIP, а именно: «базовый» механизм аутентификации HTTP, «дайджестный» механизм аутентификации HTTP и механизм аутентификации PGP (надежной конфиденциальности). Механизмы аутентификации HTTP определены в проекте стандарта RFC 2617, разработанном группой IETF и опубликованном в июне 1999 года. Содержание этого проекта стандарта целиком включено в данное описание.

Хотя для аутентификации SIP можно использовать три различных способа, для простоты вместо них можно преимущественно использовать способ САК для УСМС, и элементы, используемые для трех других способов аутентификации SIP, можно заменить элементами САК для УСМС без пересмотра формата в стандарте SIP.

Соответственно согласно настоящему изобретению ответ 401 включает в себя поле заголовка ответа для WWW-аутентификации, где содержатся векторы аутентификации САК для УСМС, то есть RAND (случайный вызов) и AUTN (маркер аутентификации).

После ответа 401 ОП посылает новый запрос REGISTER/INVITE, который должен содержать соответствующую информацию по аутентификации в поле заголовка аутентификации: ответ об аутентификации (RES), параметр нарушения синхронизации (AUTS), либо может быть послан код ошибки, если код аутентификации сообщения (КАС, MAC) признан недействительным.

Заметим, что для установки вызова, как обсуждается ниже, в альтернативном варианте для передачи параметров САК для УСМС можно использовать ответ 407 с требованием аутентификации у посредника.

В настоящем изобретении определены два варианта передачи параметров САК для УСМС в сообщениях SIP.

Как было отмечено выше, стандарт SIP определяет три различных способа аутентификации, а именно базовый способ аутентификации HTTP, «дайджестный» способ аутентификации HTTP и механизм аутентификации PGP (надежной конфиденциальности).

Таким образом, новый режим аутентификации, режим САК для УСМС, может быть определен с помощью необходимых полей. В альтернативном варианте для выполнения процедуры САК для УСМС можно повторно использовать и адаптировать существующие режимы.

Для того, чтобы можно было использовать процедуру САК для УСМС для аутентификации в подсистемах IM, необходимо определить, как параметры САК для УСМС содержатся в сообщениях SIP. Можно ввести новый способ или режим аутентификации для включения параметров САК для УСМС в сообщения SIP. Ниже изложен новый режим аутентификации согласно настоящему изобретению. Новый режим аутентификации содержит заголовки, которые выполнены как можно более короткими.

Заголовок ответа о WWW-аутентификации в случае процедуры САК для УСМС должен иметь возможность передачи как RAND, так и AUTN. Соответственно, один из примеров простого формата, который может быть использован, выглядит следующим образом:

WWW-аутентификация = "WWW-аутентификация" ":" "UMTS" RAND AUTN

RAND="RAND" "=" значение RAND

AUTN="AUTN" "=" значение AUTN

Для значений RAND и AUTN можно использовать шестнадцатеричный формат.

Заголовок проверки полномочий в случае процедуры САК для УСМС должен иметь возможность передачи значения RES или значения AUTS. Соответственно один из примеров простого формата, который можно использовать в этом случае, выглядит следующим образом:

Проверка полномочий = "Проверка полномочий" ":" "UMTS" RES | AUTS | AUTH-REJECT

RES = "RES" "=" значение RES

AUTS = "AUTS" "=" значение AUTS

AUTH-REJECT = "AUTH-REJECT" "=" код ошибки.

Для значений RES и AUTS можно использовать шестнадцатеричный формат.

Заголовок ответа для аутентификации у посредника играет по существу ту же роль, что и заголовок ответа WWW-аутентификации, и поэтому один из примеров подобного формата, который может быть использован, выглядит следующим образом:

Аутентификация = "аутентификация у посредника" ":" "UMTS"

RAND AUTN

RAND = "RAND" "=" значение RAND

AUTN = "AUTN" "=" значение AUTN

Аналогично заголовок ответа для проверки полномочий у посредника играет по существу ту же роль, что и заголовок ответа для проверки полномочий, и поэтому один из примеров подобного формата, который можно использовать, выглядит следующим образом:

Проверка полномочий у посредника = "Проверка полномочий у посредника" ":" "UMTS" RES | AUTS | AUTH-REJECT

RES = "RES" "=" значение RES

AUTS = "AUTS" "=" значение AUTS

AUTH-REJECT = "AUTH-REJECT" "=" код ошибки.

Таким образом, в случае использования механизма аутентификации согласно настоящему изобретению в подсистеме IM аутентификацию САК для УСМС можно использовать в качестве нового режима аутентификации.

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

Например, поле «для данного момента», формально используемое «дайджестным» механизмом, можно использовать для передачи сцепленных значений RAND и AUTN для САК для УСМС в шестнадцатеричном формате. Поскольку содержимое поля «для данного момента» зависит от реализации, длина этого поля должна быть достаточной для передачи значений RAND и AUTN. В другом случае для передачи части параметров для САК для УСМС можно использовать «непрозрачное» поле, определенное в упомянутом проекте стандарта.

Поле «ответа», определенное в проекте стандарта, используется для элемента RES процедуры САК для УСМС. В случае ошибки синхронизации AUTS включают в поле «ответа». Первый символ поля «ответа» может указывать на то, что ответ содержит RES, AUTS или код ошибки. RES и AUTS могут быть представлены в шестнадцатеричном формате.

При аутентификации с помощью части сообщения SIP, формально используемой для «дайджестного» режима, поле «алгоритм», которое формально определяет, какой алгоритм использовать для вычисления «дайджеста» (по умолчанию может быть использован вариант MD5), согласно настоящему изобретению может быть использовано для информирования приемника о том, что это - процедура САК для УСМС, и, таким образом, приемник узнает, что поле «для данного момента» действительно содержит RAND и AUTN.

Как было отмечено выше, для использования аутентификации в проекте стандарта SIP определен механизм PGP (надежной конфиденциальности). В альтернативном варианте этот режим можно использовать согласно настоящему изобретению для передачи параметров САК для УСМС. То есть:

Поле «для данного момента» может нести значения RAND и AUTN.

«PGP = алгоритм» может информировать приемник о том, что это процедура САК для УСМС.

Результат будет включен в поле «PGP-сигнатура». Поскольку это поле может иметь длину более 200 бит, некоторые из первых битов этого поля можно использовать для задания типа результата, например, RES, AUTS или код ошибки.

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

1. Способ аутентификации агента пользователя на сервере с использованием сообщений Протокола инициирования сеансов (SIP), заключающийся в том, что направляют запрос SIP от агента пользователя на сервер, направляют запрос на аутентификацию от сервера агенту пользователя в ответ на запрос SIP, причем запрос на аутентификацию включает в себя информацию о том, что аутентификация будет выполнена с использованием механизма соглашения об аутентификации и ключах (САК) для универсальной системы мобильной связи (УСМС), направляют ответ об аутентификации от агента пользователя на сервер в ответ на запрос на аутентификацию в соответствии с механизмом САК для УСМС, и выполняют вызываемую процедуру SIP на сервере в ответ на запрос SIP, если аутентификацию признают успешной на основании ответа об аутентификации.

2. Способ по п.1, отличающийся тем, что запрос SIP включает в себя либо запрос SIP INVITE (приглашение), либо запрос SIP REGISTER (регистрация).

3. Способ по п.1, отличающийся тем, что запрос на аутентификацию включает в себя либо код 401 SIP He разрешено, либо код 407 SIP Требование аутентификации у посредника.

4. Способ по п.3, отличающийся тем, что запрос на аутентификацию включает в себя векторы случайного вызова (RAND) и маркера аутентификации (AUTN) САК для У CMC.

5. Способ по п.4, отличающийся тем, что факторы RAND и AUTN включены в поле заголовка ответа WWW-аутентификации или аутентификации у посредника SIP.

6. Способ по п.1, отличающийся тем, что ответ об аутентификации включает в себя либо код ответа (RES) САК для УСМС или код параметра нарушения синхронизации (AUTS), либо код ошибки.

7. Способ по п.6, отличающийся тем, что ответ об аутентификации включают в поле заголовка проверки полномочий или проверки полномочий у посредника SIP.

8. Способ по п.1, отличающийся тем, что вызываемая процедура включает в себя ответ с подтверждением, содержащий код 200 SIP.

9. Устройство для аутентификации агента пользователя на сервере с использованием сообщений Протокола инициирования сеансов (SIP), содержащее средство для направления запроса SIP от агента пользователя на сервер, средство для направления запроса на аутентификацию от сервера агенту пользователя в ответ на запрос SIP, причем запрос на аутентификацию включает в себя информацию о том, что аутентификация будет выполнена с использованием механизма соглашения об аутентификации и ключах (САК) для универсальной системы мобильной связи (УСМС), средство для направления ответа об аутентификации от агента пользователя на сервер в ответ на запрос на аутентификацию в соответствии с механизмом САК для УСМС, и средство для выполнения вызываемой процедуры SIP на сервере в ответ на запрос SIP, если аутентификацию признают успешной на основании ответа об аутентификации.

10. Устройство по п.9, отличающееся тем, что запрос SIP включает в себя либо запрос SIP INVITE (приглашение), либо запрос SIP REGISTER (регистрация).

11. Устройство по п.9, отличающееся тем, что запрос на аутентификацию включает в себя либо код 401 SIP He разрешено, либо код 407 SIP Требования аутентификации у посредника.

12. Устройство по п.11, отличающееся тем, что запрос на аутентификацию включает в себя векторы случайного вызова (RAND) и маркера аутентификации (AUTN) процедуры САК для У CMC.

13. Устройство по п.12, отличающееся тем, что факторы RAND и AUTN включены в поле заголовка ответа о WWW-аутентификации или аутентификации у посредника SIP.

14. Устройство по п.9, отличающееся тем, что ответ об аутентификации включает в себя либо код ответа (RES) либо код параметра нарушения синхронизации (AUTS) процедуры САК для УСМС, либо код ошибки.

15. Устройство по п.14, отличающееся тем, что ответ об аутентификации включается в поле заголовка проверки полномочий или проверки полномочий у посредника SIP.

16. Устройство по п.9, отличающееся тем, что вызываемая процедура включает в себя ответ с подтверждением, содержащий код 200 SIP.