RU2325774C2 - Способ распределения паролей - Google Patents
Способ распределения паролей Download PDFInfo
- Publication number
- RU2325774C2 RU2325774C2 RU2006102352/09A RU2006102352A RU2325774C2 RU 2325774 C2 RU2325774 C2 RU 2325774C2 RU 2006102352/09 A RU2006102352/09 A RU 2006102352/09A RU 2006102352 A RU2006102352 A RU 2006102352A RU 2325774 C2 RU2325774 C2 RU 2325774C2
- Authority
- RU
- Russia
- Prior art keywords
- application server
- ukp
- authentication
- authentication device
- password
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
- H04W12/069—Authentication using certificates or pre-shared keys
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
- Information Transfer Between Computers (AREA)
- Burglar Alarm Systems (AREA)
- Storage Device Security (AREA)
- Computer And Data Communications (AREA)
Abstract
Способ генерации пароля, предназначенного для использования устройством конечного пользователя (УКП), чтобы осуществлять доступ к удаленному серверу, содержащий этапы, на которых посылают запрос доступа из УКП в удаленный сервер и посылают в узел аутентификации в собственной сети УКП детали запроса доступа и идентификационный код удаленного сервера. Генерируют в узле аутентификации или в удаленном сервере вызов HTTP Digest с использованием алгоритма, который может генерировать пароли конечных пользователей. Вызов включает в себя детали идентификационного кода удаленного сервера и идентификационного кода УКП. Генерируют и запоминают в УКП пароль на основании вызова HTTP Digest AKA, причем пароль связан с идентификационным кодом удаленного сервера и идентификационным кодом УКП. Технический результат - повышение безопасности связи. 2 н. и 15 з.п. ф-лы, 3 ил.
Description
Область техники, к которой относится изобретение
Изобретение относится к способу, предназначенному для распределения паролей. В частности, а не исключительно изобретение относится к способу, предназначенному для генерации пароля, предназначенного для использования устройством конечного пользователя, чтобы осуществлять доступ к удаленному серверу, где пароль сохраняют для последующего использования.
Уровень техники
Создание и распределение паролей конечного пользователя для приложений и модулей-посредников приложений являются проблематичными. С другой стороны, конечные пользователи стремятся создавать пароли, которые являются простыми и короткими и которые, следовательно, подвержены риску быть раскрытыми несанкционированными сторонами. С другой стороны, нахождение зависимости между опознавательными кодами конечных пользователей и их паролями часто является незащищенным и дорогим.
В наличии имеются механизмы, которые дают возможность повторного использования предварительно существующих паролей между различными надежными доменами, такие как решение на основании одной подписи, разработанное Альянсом Свободы. Однако часто необходимо полагаться на третью сторону, чтобы выполнить аутентификацию. Когда используется такое соглашение, провайдер службы не принимает активного участия в аутентификации. С другой стороны, управление паролем, выполняемое провайдером службы, не всегда является подходящим, поскольку обработка паролей в серверах приложений требует сложных и дорогих процедур управления, например поддержание сроков действия паролей, совмещение значений паролей, стратегии относительно допустимых значений и т.д. Кроме того, конечные пользователи не желают помнить множество паролей, и они стремятся использовать одни и те же пароли с несколькими серверами приложений, что, очевидно, уменьшает уровень защиты.
Общая схема Digest-аутентификации протокола передачи гипертекста (НТТР, ППГ), как описано в документе IETF RFC 2617, может включать в себя способы, которые могут генерировать пароли конечных пользователей. Например, Digest-аутентификация НТТР, использующая соглашение аутентификации и ключа (АКА, САК), как описано в RFC 3310, является способом, предназначенным для создания паролей конечных пользователей с использованием существующей инфраструктуры аутентификации третьего поколения (3GPP), основанной на верительных данных AKA, запомненных в устойчивом к подделке устройстве, так называемых картах ISIM/USIM/SIM. Подробности вышеупомянутых общих схем можно найти в http://www.ietf.org/rfc.html. Даже если HTTP Digest AKA предоставляет гибкий способ, чтобы генерировать новые пароли без участия пользователя, оно не включает в себя стандартный способ, чтобы делегировать эти пароли третьим сторонам, таким как серверы приложений или модули-посредники. Кроме того, HTTP Digest AKA предполагает, что пароли могут использоваться только один раз.
Сущность изобретения
Задачей изобретения является преодолеть или, по меньшей мере, уменьшить вышеупомянутые проблемы. В частности, задачей настоящего изобретения является делегировать пароли, сгенерированные с использованием HTTP Digest AKA, третьим сторонам таким образом, чтобы пароли могли безопасно использоваться для последующей аутентификации.
Эти и другие задачи выполняют с помощью начальной аутентификации, выполняемой между устройством конечного пользователя и его собственной сетью, с использованием HTTP Digest с помощью алгоритма, который может генерировать пароли, например, HTTP Digest AKA. Во время начальной аутентификации собственная сеть инициирует процесс, в котором новый пароль связывают с опознавательным кодом третьей стороны, такой как сервер приложения или модуль-посредник, и с новым временным опознавательным кодом конечного пользователя для этой третьей стороны. Устройство конечного пользователя и третья сторона могут начать использование нового пароля и связанных опознавательных кодов с использованием HTTP Digest в качестве способа аутентификации.
В соответствии с одним аспектом настоящего изобретения предоставлен способ генерации пароля, предназначенного для использования устройством конечного пользователя (UE, УКП), чтобы осуществлять доступ к удаленному серверу, содержащий этапы, на которых:
посылают запрос доступа из УКП в удаленный сервер;
создают временный идентификационный код для УКП;
посылают в узел аутентификации в собственной сети УКП детали запроса доступа;
генерируют в узле аутентификации или в удаленном сервере вызов Digest протокола передачи гипертекста (HTTP) с использованием алгоритма, который может генерировать пароли конечных пользователей, включающий в себя детали временного идентификационного кода УКП;
генерируют в УКП пароль на основании вызова HTTP Digest, причем упомянутый пароль связан с идентификационным кодом удаленного сервера и идентификационным кодом УКП; и
запоминают пароль и временный идентификационный код УКП в УКП.
Алгоритм, предназначенный для генерации паролей конечных пользователей, предпочтительно является соглашением аутентификации и ключа (AKA) HTTP Digest, хотя будет понятно, что могут использоваться другие алгоритмы.
Предпочтительно идентификационный код удаленного сервера посылают в узел аутентификации, который может генерировать вызов HTTP Digest таким образом, чтобы включать идентификационный код удаленного сервера. Идентификационный код удаленного сервера предпочтительно также запоминают в УКП.
Временный идентификационный код УКП предпочтительно создают в удаленном сервере.
В одном варианте осуществления этап, на котором посылают детали запроса доступа в узел аутентификации, может включать в себя подэтап, на котором повторно направляют запрос доступа в узел аутентификации. Затем вызов HTTP Digest может быть сгенерирован в узле аутентификации и послан из узла аутентификации непосредственно в УКП. Пароль предпочтительно запоминают в узле аутентификации.
После того как пароль сгенерирован, УКП предпочтительно аутентифицируют в узле аутентификации и запрос доступа повторно направляют из узла аутентификации обратно в удаленный сервер.
В альтернативном варианте осуществления этап, на котором посылают детали запроса доступа в узел аутентификации, может включать в себя подэтап, на котором удаленный сервер непосредственно контактирует с узлом аутентификации. Вызов HTTP Digest может быть сгенерирован в узле аутентификации и послан из узла аутентификации в удаленный сервер. В качестве альтернативного варианта удаленный сервер может генерировать вызов HTTP Digest. Затем вызов HTTP Digest посылают непосредственно из удаленного сервера в УКП.
Пароль вызова HTTP Digest AKA может быть включен в информацию, посылаемую из узла аутентификации в удаленный сервер, давая возможность УКП быть аутентифицированным в удаленном сервере. В качестве альтернативного варианта УКП может быть аутентифицировано в узле аутентификации, а результат аутентификации может быть возвращен в удаленный сервер.
Способы, описанные выше, имеют в качестве результата пароль, связанный с идентификационным кодом УКП и удаленного сервера, запомненный в УКП и в узле аутентификации или в удаленном сервере. Это дает возможность последующего доступа из УКП в удаленный сервер без необходимости генерировать дополнительный пароль. В соответствии с дополнительным аспектом настоящего изобретения предоставлен способ доступа к удаленному серверу из устройства конечного пользователя, причем способ содержит этапы, на которых:
генерируют и запоминают пароль с использованием способа, как описано выше;
посылают запрос доступа из УКП в удаленный сервер;
генерируют в удаленном сервере вызов HTTP Digest, включающий в себя детали идентификационного кода удаленного сервера и временного идентификационного кода УКП, и посылают вызов в УКП; и
посылают в УКП ответ аутентификации, включающий в себя временный идентификационный код УКП и доказательство владения паролем, в удаленный сервер.
Если пароль не запомнен в удаленном сервере, может быть необходимо послать запрос аутентификации из удаленного сервера в узел аутентификации. Затем пароль может быть послан из узла аутентификации в удаленный сервер, давая возможность аутентификации УКП в удаленном сервере. В качестве альтернативного варианта УКП может быть аутентифицировано в узле аутентификации и подтверждение аутентификации может быть послано из узла аутентификации в удаленный сервер.
Краткое описание чертежей
Фиг. 1 представляет схематическую иллюстрацию сети.
Фиг. 2А иллюстрирует последовательность, предназначенную для генерации пароля, и соглашение идентификационного кода между устройством конечного пользователя (УКП) и сервером приложения.
Фиг. 2В иллюстрирует альтернативную последовательность, предназначенную для генерации пароля, и соглашение идентификационного кода между устройством конечного пользователя (УКП) и сервером приложения.
Фиг. 3 иллюстрирует последовательность, участвующую в использовании нового пароля.
Несмотря на то что изобретение допускает различные модификации и альтернативные формы, специфичные варианты его осуществления изображены в качестве примера на чертежах и будут подробно описаны в настоящей заявке. Однако следует заметить, что это описание не предназначено для того, чтобы ограничить изобретение конкретными формами, раскрытыми в настоящей заявке, а наоборот, изобретение должно охватывать все модификации, эквивалентные варианты и альтернативные варианты, попадающие в рамки объема изобретения, как определено с помощью прилагаемой формулы изобретения.
Подробное описание предпочтительного варианта осуществления
Фиг. 1 иллюстрирует типичную схему, в которой устройство конечного пользователя (УКП) 101, соединенное с собственной сетью 102, например универсальной мобильной телекоммуникационной системой (UMTS, УМТС), желает осуществить доступ к серверу 103 приложения, соединенному с дополнительной сетью 104. УКП 101 включает в себя устойчивое к подделке устройство, такое как идентификационный модуль служб мультимедиа IP (ISIM), в котором может быть запомнена информация. В соответствии с общей схемой соглашения аутентификации и ключа (AKA) HTTP Digest заранее устанавливают совместно используемый секрет между ISIM УКП 1 и устройством 105 аутентификации в собственной сети 102. Секрет запоминают в ISIM УКП 101.
Устройство 105 аутентификации создает вектор аутентификации, основанный на совместно используемом секрете и последовательном номере. Вектор аутентификации содержит случайный вызов, аппаратный ключ аутентификации сети, ожидаемый результат аутентификации, ключ сеанса, предназначенный для проверки целостности, и ключ сеанса, предназначенный для шифрования. Вектор аутентификации загружают в сервер 103 приложения. Сервер 103 приложения создает запрос аутентификации, содержащий случайный вызов и аппаратный ключ аутентификации сети, который подают в УКП 101.
Используя совместно используемый секрет и последовательный номер, УКП 101 проверяет аппаратный ключ аутентификации сети, содержащийся в запросе аутентификации, с помощью ISIM. Если проверка является успешной, сеть аутентифицирована. Затем УКП 101 создает ответ аутентификации с использованием совместно используемого секрета и случайного вызова и подает его в сервер 103 приложения. Сервер 103 приложения сравнивает ответ аутентификации, принятый из УКП 101, с ожидаемым ответом, принятым из устройства 103 аутентификации. Если они совпадают, пользователь успешно аутентифицирован, и ключи сеанса в векторе аутентификации могут быть использованы для защиты дополнительных связей между УКП 101 и сервером 103 приложения. Однако, когда в следующий раз УКП 101 пожелает осуществить доступ к серверу 103 приложения, можно следовать той же самой процедуре, чтобы аутентифицировать сеть и получить ключи сеанса, отсутствует механизм, предназначенный для запоминания пароля для будущего использования с помощью УКП 101.
Фиг. 2 изображает один вариант осуществления системы, предназначенной для аутентификации УКП 101 в сервер 103 приложения (AS, СП). На первом этапе УКП 101 аутентифицируют с использованием HTTP Digest AKA и созданный пароль связывают с идентификационными кодами сервера 103 приложения и УКП 101. Для того чтобы понять процессы, изображенные на фиг. 2А, необходимо определить две концепции, используемые в общей схеме аутентификации HTTP Digest.
'Область действия' - это строка, которая указывает УКП 101, какое имя пользователя и пароль использовать. Эта строка содержит, по меньшей мере, имя центра 103 аутентификации и могла бы дополнительно указывать на группу пользователей, которые могли бы иметь доступ. Примером могло бы быть "registered_users@home.com" ("зарегистрированные пользователи @ собственная сеть.com"). В контексте 3GPP/AKA область действия собственной сети обычно запоминают в карте SIM/USIM/ISIM УКП 101.
'Имя пользователя' - это имя пользователя в определенной области действия. Эта строка используется сервером 103 приложения, чтобы находить правильный пароль для пользователя. В контексте 3GPP/AKA имя пользователя, используемое с собственной сетью, обычно запоминают в карте SIM/USIM/ISIM УКП 101. В большинстве случаев имя пользователя является тем же самым, что и так называемый личный идентификационный код (IMPI). Имя пользователя 3GPP идентифицирует подписку, и по этой причине пароли являются специфичными для устройства конечного пользователя, а не реального конечного пользователя. В обычной общей схеме аутентификации HTTP имя пользователя и пароль печатаются конечным пользователем, но в контексте 3GPP/AKA эти поля автоматически заполняются с помощью УКП 101.
Как изображено на фиг. 2А, на первом этапе УКП 101 и сервер 103 аутентификации не имеют совместно используемого секрета. УКП 101 сначала аутентифицируют с использованием HTTP Digest AKA и созданный пароль связывают с идентификационными кодами УКП 101 и сервера 103 приложения. Процедура имеет следующие этапы.
1а) УКП 1 посылает запрос HTTP (обычно HTTP GET) в сервер 103 приложения.
2а) Так как сервер 103 приложения и УКП 101 не имеют совместно используемого секрета, сервер 103 приложения повторно направляет запрос в устройство 105 аутентификации. Перед повторным направлением запроса сервер 103 приложения может определить новое временное имя пользователя для УКП 101. Сервер 103 приложения включает это имя пользователя и информацию своего собственного идентификационного кода в запрос. Информацию идентификационного кода обычно кодируют в параметр URI, УАР (универсальный адрес ресурса) в формате некоторого стандарта, например, "username@relm" ("имя пользователя@область действия").
3а) Устройство 105 аутентификации проверяет, чтобы понять, санкционирован ли сервер 103 приложения, чтобы выполнить повторное направление HTTP и запрос нового пароля HTTP Digest AKA для УКП 101. Если это имеет место, тогда устройство 105 аутентификации берет информацию идентификационного кода из запроса и кодирует эту информацию в вызове HTTP Digest AKA, который посылают в УКП 101. В одном варианте осуществления устройство 105 аутентификации вставляет информацию идентификационного кода в так называемые "серверные данные" данного случая HTTP Digest AKA, как описано в RFC 3310. С помощью включения идентификационного кода в вызов устройство 105 аутентификации может быть уверено, что идентификационный код сервера 103 аутентификации или временный идентификационный код конечного пользователя не может быть изменен любой стороной (такой как взломщик) между УКП 101 и устройством 103 аутентификации, поскольку вызов возвращают обратно в устройство 105 аутентификации в следующем сообщении.
4а) УКП 101 аутентифицирует сеть (как определено в стандартном протоколе AKA) и генерирует новый пароль, основанный на вызове HTTP Digest AKA. УКП локально запоминает идентификационный код сервера 103 приложения и вновь сгенерированный пароль, используемые позже для взаимной аутентификации с сервером 103 приложения. Если вызов включал также новое временное 'имя пользователя', сгенерированное с помощью сервера 103 приложения, это имя пользователя также запоминают с паролем и идентификационным кодом сервера 104 приложения. Идентификационные коды как сервера приложения, так и УКП кодируют в запросе HTTP Digest AKA, например, с использованием формата "username@realm" ("имя пользователя@область действия"). УКП 101 посылает ответ аутентификации в устройство 103 аутентификации.
Новое 'имя пользователя' отмечают как временное имя пользователя с помощью УКП 101. Это имя пользователя и связанный пароль HTTP Digest AKA удаляют, когда новое 'имя пользователя' и пароль сгенерированы для той же самой области действия. Если вызов не включает в себя новое временное имя пользователя, тогда существующее имя пользователя может быть повторно использовано.
5а) Устройство 105 аутентификации аутентифицирует УКП 101 и, если аутентификация успешна, запоминает новый пароль и идентификационные коды УКП 101 и сервера 103 приложения, используемые позже. Запрос повторно направляют обратно в сервер 103 приложения.
Если является подходящим, сервер 103 приложения может доверять начальной аутентификации, выполненной с помощью устройства 105 аутентификации. Если устройство 105 аутентификации не воспринимают как защищенное, сервер 103 аутентификации может также выполнить повторный вызов УКП 101, в текущий момент использующее вновь сгенерированный пароль. В это время HTTP Digest AKA не используется для аутентификации. Вместо этого используется HTTP Digest с некоторым другим алгоритмом, например может использоваться MD5, как описано в REC 21617.
Фиг. 2В изображает альтернативный вариант осуществления системы, предназначенной для аутентификации УКП 101 в сервер 103 приложения (СП). Первый этап выполняют с использованием другой процедуры, имеющей следующие этапы.
1b) УКП 1 посылает запрос HTTP (обычно HTTP GET) в сервер 103 приложения.
2b) Так как сервер 103 приложения и УКП 101 не имеют совместно используемого секрета, сервер 103 приложения запрашивает вызов аутентификации HTTP Digest AKA непосредственно из устройства аутентификации. Как в ранее описанном варианте осуществления запрос может включать в себя идентификационный код сервера 103 приложения и новый временный идентификационный код УКП 101.
3b) Устройство 105 аутентификации проверяет, чтобы понять, санкционирован ли сервер 103 приложения, чтобы запросить новый пароль HTTP Digest AKA для УКП 101. Если это имеет место, тогда устройство аутентификации берет информацию идентификационного кода сервера приложения и временного идентификационного кода конечного пользователя (если присутствует) из запроса и кодирует эту информацию в вызове HTTP Digest AKA, как в ранее описанном варианте осуществления. В качестве альтернативного варианта сервер 103 приложения также может включать эту информацию в вызов на этапе 4b, описанном ниже. Информацию идентификационного кода кодируют в формате некоторого стандарта, например, username@relm (имя пользователя@область действия) или username@remote_realm (имя пользователя@удаленное устройство_область действия). Информацию, требуемую сервером 103 приложения, чтобы создать вызов HTTP Digest AKA, посылают обратно в сервер 103 приложения. Если эти параметры включают в себя пароль HTTP Digest AKA, тогда этапы 6b) и 7b) могут не требоваться.
4b) УКП 101 вызывают с помощью вызова аутентификации HTTP Digest AKA. Сервер 103 приложения может добавить идентификационные коды сервера приложения и конечного пользователя в вызов аутентификации перед посылкой вызова в УКП 101. Однако в этом случае сервер 103 приложения должен быть конечным пунктом для аутентификации и должен обладать паролем HTTP Digest AKA.
5b) УКП 101 аутентифицирует сеть (как определено в стандартном протоколе AKA) и генерирует новый пароль, основанный на вызове HTTP Digest AKA. УКП локально запоминает идентификационный код сервера 103 приложения (например, "область действия"), вновь сгенерированный пароль и новое временное 'имя пользователя' для себя (если присутствует), используемые позже сервером 103 приложения для взаимной аутентификации с сервером 103 приложения (если присутствует). УКП 101 посылает ответ аутентификации в сервер 103 приложения. Как в ранее описанном варианте осуществления УКП 101 отмечает возможное новое 'имя пользователя' как временное имя пользователя.
6b) Если сервер 103 приложения не принял пароль конечного пользователя на этапе 3b выше, он теперь запрашивает устройство 105 аутентификации выполнить аутентификацию.
7b) Если сервер 103 приложения не принял пароль конечного пользователя на этапе 3b выше и он запросил аутентификацию на этапе 6b), устройство 105 аутентификации аутентифицирует УКП 101 и возвращает соответствующий результат в сервер 103 приложения. Устройство 105 аутентификации также может послать пароль конечного пользователя в сервер 103 приложения на этом или некотором более позднем этапе.
8b) Если аутентификация УКП 101 была успешной, службу подают в УКП 101.
Следование процедурам, описанным выше со ссылкой на фиг. 2A либо фиг. 2B, имеет результатом то, что сервер 103 приложения и УКП 101 имеют совместно используемый секрет. В следующий раз, когда сервер 103 приложения должен будет аутентифицировать УКП 101 (что может быть непосредственно после предыдущих процедур или после некоторого более длительного периода времени, например, в следующий раз, когда УКП 101 будет контактировать с сервером 103 приложения), процедура является такой, как изображена на фиг. 3.
1с) УКП 101 посылает запрос HTTP (обычно HTTP GET) в сервер 103 приложения.
2с) Так как сервер 103 приложения и УКП 101 теперь имеют совместно используемый секрет, сервер 103 приложения вызывает УКП 101 с помощью вызова HTTP Digest. Вызов включает в себя идентификационный код сервера 103 приложения в параметре 'область действия'.
3с) УКП 101 посылает ответ аутентификации (обычно запрос HTTP GET) обратно в сервер 103 приложения с использованием нового временного 'имени пользователя' и пароля для сервера 103 приложения, созданных во время предыдущего этапа (описанного выше со ссылкой на фиг. 2В или фиг. 2С). Если новое временное имя пользователя не было создано, тогда используется обычное специфичное имя пользователя AKA. УКП 101 использует параметр "область действия", чтобы идентифицировать правильный пароль.
4с) Если сервер 103 приложения обладает паролем конечного пользователя, этот этап и следующий этап (5с) не требуются. Если сервер 103 приложения не обладает паролем конечного пользователя, тогда сервер 103 приложения запрашивает из устройства 105 аутентификации (или некоторого другого объекта сети (не изображен), где устройство 105 аутентификации запомнило специфичный пароль УКП) аутентификацию.
5с) На этом этапе имеются две различные возможности. Устройство 105 аутентификации может позаботиться об аутентификации от имени сервера 103 приложения. В этом случае серверу 103 приложения не требуется знать пароль и устройство 105 аутентификации просто возвращает информацию в сервер 103 аутентификации относительно того, была ли аутентификация успешной или нет. В качестве альтернативного варианта устройство 105 аутентификации может послать пароль в сервер 103 приложения, который затем выполняет аутентификацию.
Если аутентификация была успешной, СП подает службу в УКП.
Будет понятно, что изменения из описанных выше вариантов осуществления по-прежнему могут находиться в рамках объема изобретения. Например, как указано в REC 21617, от устройства аутентификации фактически не требуется знать пароль понятного текста пользователя. Поскольку классифицированное значение имени пользователя, области действия и пароля является доступным для сервера, может быть проверена допустимость заголовка аутентификации.
Claims (17)
1. Способ генерации пароля, предназначенного для использования устройством конечного пользователя (УКП), чтобы осуществлять доступ к серверу приложения, содержащий этапы, на которых
посылают запрос доступа из УКП в сервер приложения;
создают временный идентификационный код для УКП;
посылают в устройство аутентификации в собственной сети УКП детали запроса доступа, содержащие упомянутый временный идентификационный код для УКП;
проверяют в устройстве аутентификации, санкционирован ли сервер приложения для выполнения операции повторного направления с использованием HTTP и запроса нового пароля HTTP Digest AKA для УКП;
генерируют в устройстве аутентификации или в сервере приложения вызов Digest протокола передачи гипертекста (HTTP), включающий в себя детали временного идентификационного кода УКП;
генерируют в УКП пароль на основании вызова HTTP Digest, причем упомянутый пароль связан с идентификационным кодом сервера приложения и идентификационным кодом УКП; и запоминают пароль и временный идентификационный код УКП в УКП.
2. Способ по п.1, в котором этап генерации пароля основан на соглашении аутентификации и ключа (AKA) HTTP Digest.
3. Способ по п.1, дополнительно содержащий этап, на котором посылают идентификационный код сервера приложения в устройство аутентификации, в котором этап, на котором генерируют вызов HTTP Digest, включает в себя подэтап, на котором используют идентификационный код сервера приложения и в котором идентификационный код сервера приложения запоминают в УКП.
4. Способ по п.1, в котором временный идентификационный код УКП создают в сервере приложения.
5. Способ по п.1, в котором этап, на котором посылают детали запроса доступа в устройство аутентификации, включает в себя подэтап, на котором повторно направляют запрос доступа в устройство аутентификации.
6. Способ по п.5, в котором вызов HTTP Digest генерируют в устройстве аутентификации и посылают из устройства аутентификации непосредственно в УКП.
7. Способ по п.5, в котором пароль запоминают в устройстве аутентификации.
8. Способ по п.5, дополнительно содержащий этапы, на которых УКП аутентифицируют в устройстве аутентификации и повторно направляют запрос доступа из устройства аутентификации обратно в сервер приложения после того, как пароль сгенерирован.
9. Способ по п.1, в котором этап, на котором посылают детали запроса доступа в устройство аутентификации, включает в себя подэтап, на котором сервер приложения непосредственно контактирует с устройством аутентификации.
10. Способ по п.9, в котором вызов HTTP Digest генерируют в устройстве аутентификации и посылают из устройства аутентификации в сервер приложения.
11. Способ по п.9, в котором вызов HTTP Digest генерируют в сервере приложения.
12. Способ по п.10, дополнительно содержащий этап, на котором посылают вызов HTTP Digest АКА из сервера приложения в УКП.
13. Способ по п.11, дополнительно содержащий этапы, на которых включают пароль вызова HTTP Digest АКА в информацию, посылаемую из устройства аутентификации в сервер приложения, и аутентифицируют УКП в сервере приложения.
14. Способ по п.9, дополнительно содержащий этапы, на которых УКП аутентифицируют в устройстве аутентификации и возвращают результат аутентификации в сервер приложения.
15. Способ доступа к серверу приложения из устройства конечного пользователя (УКП), причем способ содержит этапы, на которых
генерируют и запоминают пароль в УКП, используя способ по любому одному из предшествующих пунктов;
посылают запрос доступа из УКП в сервер приложения;
генерируют в сервере приложения вызов Digest протокола передачи гипертекста (HTTP), включающий в себя детали идентификационного кода сервера приложения, и посылают вызов в УКП; и посылают из УКП ответ аутентификации, включающий в себя временный идентификационный код УКП, в сервер приложения.
16. Способ по п.15, дополнительно содержащий этапы, на которых посылают запрос аутентификации из сервера приложения в устройство аутентификации, посылают пароль из устройства аутентификации в сервер приложения и аутентифицируют УКП в сервере приложения.
17. Способ по п.15, дополнительно содержащий этапы, на которых посылают запрос аутентификации из сервера приложения в устройство аутентификации, аутентифицируют УКП в устройстве аутентификации и посылают подтверждение аутентификации из устройства аутентификации в сервер приложения.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GBGB0314971.3A GB0314971D0 (en) | 2003-06-27 | 2003-06-27 | Method for distributing passwords |
| GB0314971.3 | 2003-06-27 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| RU2006102352A RU2006102352A (ru) | 2006-08-27 |
| RU2325774C2 true RU2325774C2 (ru) | 2008-05-27 |
Family
ID=27637440
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2006102352/09A RU2325774C2 (ru) | 2003-06-27 | 2004-06-24 | Способ распределения паролей |
Country Status (10)
| Country | Link |
|---|---|
| US (1) | US20070005730A1 (ru) |
| EP (1) | EP1639782B1 (ru) |
| KR (1) | KR20060032602A (ru) |
| CN (1) | CN100556033C (ru) |
| AT (1) | ATE387795T1 (ru) |
| DE (1) | DE602004012103T2 (ru) |
| ES (1) | ES2300792T3 (ru) |
| GB (1) | GB0314971D0 (ru) |
| RU (1) | RU2325774C2 (ru) |
| WO (1) | WO2005002166A2 (ru) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3791489B2 (ja) * | 2002-12-13 | 2006-06-28 | ソニー株式会社 | ポータブルサーバ |
| KR100664312B1 (ko) | 2005-01-20 | 2007-01-04 | 삼성전자주식회사 | 홈 네트워크 환경에서 홈 디바이스 인증 방법 및 장치 |
| CA2594468A1 (en) * | 2005-01-28 | 2006-08-03 | Telefonaktiebolaget Lm Ericsson (Publ) | User authentication and authorisation in a communications system |
| US7631346B2 (en) * | 2005-04-01 | 2009-12-08 | International Business Machines Corporation | Method and system for a runtime user account creation operation within a single-sign-on process in a federated computing environment |
| US7861077B1 (en) * | 2005-10-07 | 2010-12-28 | Multiple Shift Key, Inc. | Secure authentication and transaction system and method |
| CN101317181B (zh) * | 2005-10-21 | 2010-05-19 | 诺基亚公司 | 用于移动终端中安全鉴权响应的设备以及方法 |
| US8091122B2 (en) * | 2005-12-05 | 2012-01-03 | Nokia Corporation | Computer program product, apparatus and method for secure HTTP digest response verification and integrity protection in a mobile terminal |
| US8712802B1 (en) | 2007-10-08 | 2014-04-29 | United Services Automobile Association (Usaa) | Transferring a document |
| US8156550B2 (en) * | 2008-06-20 | 2012-04-10 | Microsoft Corporation | Establishing secure data transmission using unsecured E-mail |
| US20130275492A1 (en) * | 2012-04-13 | 2013-10-17 | Microsoft Corporation | Enabling Web Clients to Provide Web Services |
| CN103647695A (zh) * | 2013-10-31 | 2014-03-19 | 北京奇虎科技有限公司 | 一种客户端应用程序的用户注册方法、移动终端及服务器 |
| US11095449B2 (en) * | 2016-12-16 | 2021-08-17 | Visa International Service Association | System and method for securely processing an electronic identity |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6891819B1 (en) * | 1997-09-05 | 2005-05-10 | Kabushiki Kaisha Toshiba | Mobile IP communications scheme incorporating individual user authentication |
| US6092196A (en) * | 1997-11-25 | 2000-07-18 | Nortel Networks Limited | HTTP distributed remote user authentication system |
| US6223287B1 (en) * | 1998-07-24 | 2001-04-24 | International Business Machines Corporation | Method for establishing a secured communication channel over the internet |
| JP2000092046A (ja) * | 1998-09-11 | 2000-03-31 | Mitsubishi Electric Corp | 遠隔認証システム |
| FI19992343A (fi) * | 1999-10-29 | 2001-04-30 | Nokia Mobile Phones Ltd | Menetelmä ja järjestely käyttäjän luotettavaksi tunnistamiseksi tietokonejärjestelmässä |
| US6839761B2 (en) * | 2001-04-19 | 2005-01-04 | Microsoft Corporation | Methods and systems for authentication through multiple proxy servers that require different authentication data |
| US7191467B1 (en) * | 2002-03-15 | 2007-03-13 | Microsoft Corporation | Method and system of integrating third party authentication into internet browser code |
| US7380124B1 (en) * | 2002-03-28 | 2008-05-27 | Nortel Networks Limited | Security transmission protocol for a mobility IP network |
| FI20020733A0 (fi) * | 2002-04-16 | 2002-04-16 | Nokia Corp | Menetelmä ja järjestelmä tiedonsiirtolaitteen käyttäjän autentikointiin |
| JP2004032253A (ja) * | 2002-06-25 | 2004-01-29 | Hitachi Ltd | ネットワーク通信装置および通信方式 |
| US20040043756A1 (en) * | 2002-09-03 | 2004-03-04 | Tao Haukka | Method and system for authentication in IP multimedia core network system (IMS) |
| US7865931B1 (en) * | 2002-11-25 | 2011-01-04 | Accenture Global Services Limited | Universal authorization and access control security measure for applications |
| US7421732B2 (en) * | 2003-05-05 | 2008-09-02 | Nokia Corporation | System, apparatus, and method for providing generic internet protocol authentication |
-
2003
- 2003-06-27 GB GBGB0314971.3A patent/GB0314971D0/en not_active Ceased
-
2004
- 2004-06-24 RU RU2006102352/09A patent/RU2325774C2/ru not_active IP Right Cessation
- 2004-06-24 KR KR1020057025078A patent/KR20060032602A/ko not_active Application Discontinuation
- 2004-06-24 DE DE602004012103T patent/DE602004012103T2/de active Active
- 2004-06-24 US US10/595,016 patent/US20070005730A1/en not_active Abandoned
- 2004-06-24 EP EP04741888A patent/EP1639782B1/en not_active Not-in-force
- 2004-06-24 WO PCT/EP2004/051233 patent/WO2005002166A2/en active IP Right Grant
- 2004-06-24 CN CNB2004800179849A patent/CN100556033C/zh not_active Expired - Fee Related
- 2004-06-24 ES ES04741888T patent/ES2300792T3/es active Active
- 2004-06-24 AT AT04741888T patent/ATE387795T1/de not_active IP Right Cessation
Non-Patent Citations (1)
| Title |
|---|
| NIEMI A ET AL: "HTTP Digest Authentication Using AKA, NETWORK. WORKING GROUP INTERNET-DRAFT, draft-ietf-sip-digest-aka-01", 25.04.2002. http:/www.tech-invite.com/RFCs/PDF/RFC3310.pdf. FRANKS J ET AL: "An Extension to HTTP: Digest Access Authentication", январь 1997. http:/www.ietf.org/rfc/rfc2069.txt. * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20070005730A1 (en) | 2007-01-04 |
| DE602004012103D1 (de) | 2008-04-10 |
| ATE387795T1 (de) | 2008-03-15 |
| DE602004012103T2 (de) | 2009-03-12 |
| ES2300792T3 (es) | 2008-06-16 |
| WO2005002166A3 (en) | 2005-05-26 |
| EP1639782A2 (en) | 2006-03-29 |
| EP1639782B1 (en) | 2008-02-27 |
| CN1813455A (zh) | 2006-08-02 |
| GB0314971D0 (en) | 2003-07-30 |
| CN100556033C (zh) | 2009-10-28 |
| KR20060032602A (ko) | 2006-04-17 |
| WO2005002166A2 (en) | 2005-01-06 |
| RU2006102352A (ru) | 2006-08-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8769655B2 (en) | Shared registration multi-factor authentication tokens | |
| US6993652B2 (en) | Method and system for providing client privacy when requesting content from a public server | |
| US8499339B2 (en) | Authenticating and communicating verifiable authorization between disparate network domains | |
| US7774612B1 (en) | Method and system for single signon for multiple remote sites of a computer network | |
| KR101475981B1 (ko) | 만료된 패스워드 처리 | |
| EP2637351A1 (en) | Method and system for single sign-on | |
| WO2006000144A1 (fr) | Procede d'identification de protocole initial de session | |
| Harrison | Lightweight directory access protocol (LDAP): Authentication methods and security mechanisms | |
| WO2011144081A2 (zh) | 用户业务鉴权方法、系统及服务器 | |
| CN112261022A (zh) | 一种基于api网关的安全认证方法 | |
| RU2325774C2 (ru) | Способ распределения паролей | |
| DK2414983T3 (en) | Secure computer system | |
| US11146536B2 (en) | Method and a system for managing user identities for use during communication between two web browsers | |
| US8464067B2 (en) | Method for enabling limitation of service access | |
| KR100993333B1 (ko) | 인터넷 접속 도구를 고려한 사용자 인증 방법 및 시스템 | |
| TWI759090B (zh) | 平台登入方法 | |
| CN117978412A (zh) | Api认证方法、转换网关、管理平台及电子设备 | |
| WO2011017851A1 (zh) | 客户端安全访问消息存储服务器的方法和相关设备 | |
| Alenius et al. | Centralised Authentication | |
| Kemp et al. | Authentication Context for the OASIS Security Assertion Markup Language | |
| Maler et al. | Authentication Context for the OASIS Security Assertion Markup Language | |
| Machani et al. | Internet Engineering Task Force (IETF) A. Doherty Request for Comments: 6063 RSA, The Security Division of EMC Category: Standards Track M. Pei | |
| Aarts et al. | Liberty ID-FF Authentication Context Specification | |
| Core | Network Working Group P. Saint-Andre Internet-Draft J. Miller Expires: August 31, 2003 Jabber Software Foundation March 2, 2003 | |
| WO2000069115A1 (en) | A method and apparatus for accessing a computer using a browser |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MM4A | The patent is invalid due to non-payment of fees |
Effective date: 20140625 |