RU2447603C2 - Способ передачи сообщений dhcp - Google Patents

Способ передачи сообщений dhcp Download PDF

Info

Publication number
RU2447603C2
RU2447603C2 RU2009118395/08A RU2009118395A RU2447603C2 RU 2447603 C2 RU2447603 C2 RU 2447603C2 RU 2009118395/08 A RU2009118395/08 A RU 2009118395/08A RU 2009118395 A RU2009118395 A RU 2009118395A RU 2447603 C2 RU2447603 C2 RU 2447603C2
Authority
RU
Russia
Prior art keywords
dhcp
key
server
network
telecommunications network
Prior art date
Application number
RU2009118395/08A
Other languages
English (en)
Other versions
RU2009118395A (ru
Inventor
Домагой ПРЕМЕК (HR)
Домагой Премек
Максимилиан РИГЕЛЬ (DE)
Максимилиан РИГЕЛЬ
Original Assignee
Нокиа Сименс Нетворкс Гмбх Унд Ко. Кг
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Нокиа Сименс Нетворкс Гмбх Унд Ко. Кг filed Critical Нокиа Сименс Нетворкс Гмбх Унд Ко. Кг
Publication of RU2009118395A publication Critical patent/RU2009118395A/ru
Application granted granted Critical
Publication of RU2447603C2 publication Critical patent/RU2447603C2/ru

Links

Images

Classifications

    • 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
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • 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/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • 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/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • 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/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0433—Key management protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/061—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying further key derivation, e.g. deriving traffic keys from a pair-wise master key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121—Timestamp
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Настоящее изобретение относится к способу передачи сообщения DHCP между телекоммуникационной сетью, главным образом телекоммуникационной сетью, соответствующей стандарту WiMAX, и абонентом межсетевого протокола (IP) в телекоммуникационной сети. Технический результат изобретения заключается в улучшении защиты при обмене сообщениями DHCP между телекоммуникационной сетью и абонентом IP. В соответствии с изобретением, к сообщению DHCP добавляется информация, защищенная с помощью ключа шифрования. Ключ шифрования выводится из основного ключа, обеспечиваемого сетевым компонентом телекоммуникационной сети. 2 н. и 18 з.п. ф-лы, 4 ил.

Description

Изобретение относится к способу передачи сообщения DHCP (протокола динамической конфигурации хост-машины) между телекоммуникационной сетью, главным образом телекоммуникационной сетью в соответствии со стандартом WiMAX (общемировая совместимость широкополосного беспроводного доступа), и абонентом межсетевого протокола (IP) в телекоммуникационной сети.
В последующем описании для объяснения проблемы, лежащей в основе настоящего изобретения, делается ссылка на телекоммуникационную сеть WiMAX. Эта ссылка на телекоммуникационную сеть WiMAX является только примером. Фактически, изобретение относится к любому виду телекоммуникационной сети.
Сеть WiMAX состоит из сети предоставления услуг с возможностью взаимодействия (CSN) WiMAX, которая сопоставима с основной сетью и сетью предоставления услуг доступа (ASN) WiMAX, выполняющей роль сети с беспроводным доступом. ASN и CSN могут использоваться различными коммерческими организациями или операторами. Общая архитектура сети WiMAX показана на фиг.1, которая изображает эталонную модель сети WiMAX. Подробное описание эталонной модели сети можно найти по адресу www.WiMAXforum.org/technology/documents/ в описании "WiMAX end-to-end network systems architecture", Chapter 6, "Network Reference Model" ("Сквозная архитектура сетевых систем WiMAX", глава 6, "Эталонная модель сети"). Содержание этого проекта описания включено в данное описание путем ссылки.
CSN всегда содержит собственное исполнительное устройство абонента WiMAX. Собственное исполнительное устройство не может быть размещено в ASN. Собственное исполнительное устройство имеет задачу защиты домашнего адреса абонента в его домашней сети (CSN), в то время как абонент находится вне дома. Это означает, что домашний адрес абонента является топологически правильным в подсети, где размещено собственное исполнительное устройство, и домашний адрес как таковой должен выделяться доменом CSN. Домашняя сеть абонента WiMAX может динамически задаваться, и это может происходить либо в домашней CSN (Н-CSN), либо в посещаемой CSN (V-CSN), в зависимости от соглашения роуминга между домашним и посещаемым поставщиком сетевых услуг WiMAX (NSP).
Особенность архитектуры сети WiMAX заключается в поддержке так называемых терминалов "простого межсетевого протокола (IP)" как абонента, который не содержит реализацию стека IP мобильной связи. Подвижность на сетевом (IP) уровне для этих устройств управляется с помощью ASN посредством IP мобильной связи модуля-посредника.
Терминалы простого IP используют DHCP для приобретения IP-адреса и других параметров конфигурации IP. IP-адрес для терминала простого IP выделяется посредством CSN (либо Н-CSN, либо V-CSN), но присваивание этого адреса терминалу выполняется сетью доступа ASN. Для присваивания этого адреса в ASN должен быть обеспечен ретранслятор DHCP. В противоположность этому, сервер DHCP размещен в CSN, и ретранслятор DHCP в ASN ретранслирует сообщения DHCP от терминала простого IP к серверу DHCP в CSN. В этом сценарии во время аутентификации абонента CSN обеспечивает ASN IP-адресом сервера DHCP в CSN. Этот адрес позже используется ретранслятором DHCP в ASN для того, чтобы ретранслировать сообщения DHCP от терминала к надлежащему серверу DHCP. Сервер DHCP может быть размещен либо в V-CSN, либо в Н-CSN. В этих случаях предполагается, что ASN и CSN могут быть разделены неизвестной глобальной сетью IP, например, общедоступным Интернетом. Что касается фиг.1, то на ней контрольные точки R3 и R5 могут сталкиваться с такой незащищенной инфраструктурой IP.
Из-за этой топологии телекоммуникационной сети сервер DHCP в CSN является уязвимым относительно различных типов атак. Атаки могут исходить как от незащищенной сети, подключающей ASN и CSN, так и от аутентифицированных, но плохо себя ведущих абонентов WiMAX. Этих атак можно избегать, если ретранслятор DHCP в ASN и сервер DHCP в CSN используют дополнительную опцию аутентификации исполнительного устройства ретранслятора, как определено в RFC 4030 (Запросы на комментарии) (http://rfc.net/rfc4030.html). Способы, определяемые в RFC 4030, предусматривают аутентификацию, защиту целостности и защиту воспроизведения сообщений DHCP. Таким образом, предполагается, что ретранслятор DHCP и сервер DHCP совместно используют секретный ключ, используемый для вычисления криптогафической контрольной суммы, которая обеспечивает упомянутую выше защиту.
Поэтому целью настоящего изобретения является улучшение защиты при обмене сообщениями DHCP между телекоммуникационной сетью и абонентом IP.
В соответствии с изобретением, обеспечен способ передачи сообщения DHCP между телекоммуникационной сетью, главным образом телекоммуникационной сетью в соответствии со стандартом WiMAX, и абонентом межсетевого протокола (IP) в телекоммуникационной сети, в котором к сообщению DHCP добавляется информация, защищенная ключом шифрования, и в котором ключ шифрования выводится из основного ключа, обеспечиваемого сетевым компонентом телекоммуникационной сети.
Благодаря защите некоторой информации с помощью ключа шифрования, который выводят из основного ключа, можно обеспечить максимальную защиту от неправильного использования. Ключ шифрования как раз используется для того, чтобы защищать информацию, которая добавляется к сообщению DHCP, но не само сообщение DHCP. Это означает, что ключ шифрования используется для того, чтобы отмечать в цифровой форме сообщение. Только объект, владеющий ключом шифрования, сможет вычислить сигнатуру, таким образом верифицируя сообщение. Отправляющий объект вычисляет сигнатуру сообщения (используя ключ шифрования как часть вычисления) и добавляет сигнатуру к сообщению. Принимающий объект (также владеющий ключом шифрования) повторно отдельно вычисляет сигнатуру и сравнивает результат с сигнатурой, принятой в сообщении. Если они соответствуют, принимающий объект может быть уверенным в том, что принятое сообщение было подписано объектом, владеющим ключом шифрования (и что сообщение не подделывалось по пути следования). Ключи шифрования можно динамически получать из основного ключа для того, чтобы предохранять сообщения DHCP.
В соответствии с другим вариантом осуществления ключ шифрования используется для того, чтобы защищать сообщения DHCP, обмениваемые между сервером DHCP и ретранслятором DHCP, факультативно размещенными в различных сетях (подсетях) телекоммуникационной сети. Сервер DHCP может быть размещен в основной сети, такой как CSN, тогда как ретранслятор DHCP может быть размещен в сети доступа, такой как ASN в телекоммуникационной сети WiMAX. Вследствие использования ключа шифрования для защиты сообщений DHCP, обмениваемых между сервером DHCP и ретранслятором DHCP, сообщения могут передаваться через незащищенную инфраструктуру IP без опасения, что сервер DHCP может стать объектом атак.
В соответствии с другим вариантом осуществления сообщение DHCP, генерируемое абонентом, перехватывается телекоммуникационной сетью, в которой добавляется информация, зашифрованная с помощью ключа шифрования, когда сообщение DHCP соответствует проверкам защиты и/или правдоподобия. Перехватывание и проверка сообщения DHCP могут выполняться ретранслятором DHCP. Перехватывание и проверка включают в себя однонаправленный поток обмена информацией, который направлен к серверу DHCP. Таким образом, может быть выполнена верификация содержания каждого сообщения DHCP. В случае, если сообщение DHCP проходит различные проверки защиты и/или правдоподобия относительно получения доступа путем обмана, атак DoS и т.д., к сообщению будет добавляться информация, зашифрованная с помощью ключа шифрования, таким образом давая гарантию телекоммуникационной сети, главным образом серверу DHCP, что это законное сообщение DHCP.
В соответствии с другим вариантом осуществления основной ключ может генерироваться с использованием генерируемого случайного значения. Случайное значение может генерироваться ААА-сервером в домашней сети абонента. ААА-сервер может быть размещен в основной сети, например, в CSN. По соображениям безопасности основной ключ может быть определенным для сервера DHCP. Ключи, генерируемые ААА-сервером, могут транспортироваться в сервер DHCP, используя протокол RADIUS. Протокол RADIUS может дополнительно использоваться для транспортирования основного ключа в расширяемый протокол аутентификации, или аутентификатор (IAP), как будет описано позже.
В соответствии с другим вариантом осуществления основной ключ и идентификатор связанного ключа, где связанный ключ идентифицирует, соответственно, основной ключ, пересылаются от ААА-сервера домашней сети абонента, предпочтительно в сообщении запроса доступа, в сеть доступа, обслуживающую абонента. Идентификатор связанного ключа может генерироваться ААА-сервером.
В соответствии с другим вариантом осуществления ключ шифрования выводится конкретно для каждого шлюза сети доступа в соответствующей сети предоставления услуг доступа, причем шлюз сети доступа действует для абонента, как ретранслятор DHCP. Это означает, что из основного ключа выводятся дополнительные ключи шифрования, которые являются определенными для каждой пары ретранслятора DHCP/сервера DHCP, в которой эти ключи используются для защиты сообщений DHCP, обмениваемых между телекоммуникационной сетью и абонентом, главным образом между ретрансляторами DHCP и сервером DHCP. Основной ключ и выводимые ключи связаны не с индивидуальным пользователем или сеансами аутентификации, а с определенным сервером DHCP и парой ретранслятора DHCP/сервера DHCP.
Определенный ключ шифрования шлюза сети доступа генерируется с использованием основного ключа.
В другом варианте осуществления определенный ключ шифрования шлюза сети доступа используется для того, чтобы вычислять дополнительную опцию аутентификации исполнительного устройства ретранслятора в качестве информации защиты. Это означает, что для вычисления дополнительной опции аутентификации исполнительного устройства ретранслятора используется не основной ключ, а вместо этого ключ шифрования, который выводится из основного ключа и который является определенным для шлюза сети доступа. Шлюз сети доступа действует для абонента, как ретранслятор DHCP. Предложенный путь создания выводимого ключа шифрования, определенного для каждого шлюза сети прикладных программ, состоит в том, чтобы включать IP-адрес шлюза сети прикладных программ в процесс выведения ключа.
Когда сервер DHCP в основной сети принимает сообщение DHCP, содержащее дополнительную опцию аутентификации исполнительного устройства ретранслятора, он должен верифицировать эту дополнительную опцию аутентификации. В случае, если сервер DHCP не имеет основного ключа, все еще соответствующего идентификатору ключа, содержащемуся в принятой дополнительной опции аутентификации, сервер DHCP может запросить основной ключ от ААА-сервера. Это может быть выполнено таким же способом, каким собственное исполнительное устройство запрашивает корневой ключ собственного исполнительного устройства (HA-RK), когда необходимо верифицировать расширение аутентификации внешнего исполнительного устройства - собственного исполнительного устройства (FA-HA) в сообщении запроса регистрации IP мобильной связи. Сервер DHCP может использовать сообщение запроса доступа для того, чтобы запросить основной ключ от ААА-сервера. Сервер DHCP должен включить значение поля идентификатора ключа из дополнительной опции аутентификации принятого сообщения DHCP в сообщение запрета доступа. ААА-сервер поставляет основной ключ, соответствующий серверу DHCP и указанному идентификатору ключа для запрашивающего сервера DHCP, в сообщение принятия доступа. В случае если идентификатор ключа ААА-серверу не известен, ААА-сервер посылает в сервер DHCP отклонение доступа. С другой стороны, если основной ключ, связанный с принятым идентификатором ключа, в сервере DHCP уже имеется, серверу DHCP не требуется запрашивать основной ключ у ААА-сервера. В этом случае сервер DHCP будет использовать уже имеющийся основной ключ. Как только основной ключ оказывается в сервере DHCP, он генерирует ключ шифрования, определенный для этого ретранслятора DHCP, и использует генерируемый ключ для верифицирования дополнительной опции аутентификации. Сервер DHCP также включает дополнительную опцию аутентификации исполнительного устройства ретранслятора в свой ответ, используя для его вычисления требуемый ключ шифрования.
В другом варианте осуществления изобретения основной ключ, связанный идентификатором ключа и временем существования основного ключа, будет поддерживаться в шлюзе сети доступа, действующем как аутентификатор расширяемого протокола аутентификации (EAP), до тех пор, пока не истечет время существования основного ключа.
В соответствии с другим вариантом осуществления ключ шифрования, идентификатор ключа и счетчик выявлений воспроизведения будут поддерживаться в шлюзе сети доступа, действующем для абонента, как ретранслятор DHCP.
В соответствии с другим вариантом осуществления идентификатор ключа и значения выявлений воспроизведения передаются от старого ретранслятора DHCP в новый ретранслятор DHCP в виде части контекста, через определенные служебные сообщения, главным образом WiMAX.
В любой момент времени ААА-сервер может иметь несколько допустимых основных ключей, являющихся определенными для единственного сервера DHCP. Эти основные ключи должны иметь разные идентификаторы ключей и могут иметь разное время существования. Таким образом, гарантировано бесшовное обновление основных ключей, обеспечивающее возможность того, чтобы и старый, и новый основной ключ сосуществовали и одновременно использовались в течение некоторого периода времени.
В другом варианте осуществления, когда сервер DHCP в домашней сети абонента принимает сообщение DHCP от ретранслятора DHCP сети доступа, для которого еще не имеется ключа шифрования, но дополнительная опция аутентификации указывает идентификатор ключа, уже известный серверу DHCP, сервер DHCP генерирует новый ключ шифрования из известного основного ключа, связанного с принятым идентификатором ключа.
В соответствии с другим вариантом осуществления используются правила выведения для ключей кодирования и для основных ключей.
Изобретение также содержит компонент или компоненты телекоммуникационной сети для выполнения способа в соответствии с любым из описанных выше путей.
Изобретение обеспечивает возможность соединения ретранслятора DHCP в сети доступа и сервера DHCP в основной сети через незащищенную сеть IP, такую как Интернет. Благодаря обеспечению эффективного механизма распределения ключей можно обеспечивать дополнительную опцию аутентификации исполнительного устройства ретранслятора в сообщениях DHCP, которая препятствует ситуации, когда сервер DHCP в основной сети подвергается различным типам атак. Поскольку ключи шифрования, используемые для защиты сообщений DHCP, выводятся динамически и имеют ограниченное время существования, ограничиваемое временем существования сеанса связи абонента, обеспеченный способ имеет возможность очень большого распространения.
Изобретение будет также описано посредством примера и со ссылкой на прилагаемые чертежи.
Фиг.1 показывает эталонную модель сети в соответствии с телекоммуникационной сетью WiMAX.
Фиг.2 показывает ключевую иерархию WiMAX.
Фиг.3 показывает процесс начального распределения ключей DHCP, и
Фиг.4 показывает схематическое представление распределения ключей DHCP в случае, если аутентификатор и ретранслятор DHCP не размещены совместно.
Настоящее изобретение будет описано со ссылкой на телекоммуникационную сеть WiMAX. На фиг.1 иллюстрируется известная эталонная модель сети WiMAX. Особенность архитектуры телекоммуникационной сети WiMAX заключается в поддерживании терминалов "простого IP" SS/MS (стационарные станции/мобильные станции). Эти терминалы простого IP SS/MS используют DHCP (протокол динамической конфигурации хост-машины) для того, чтобы приобретать IP-адрес и другие параметры конфигурации IP. IP-адрес для терминала IP SS/MS, который будет упоминаться как абонент, выделяется сетью предоставления услуг с возможностью взаимодействия WiMAX (CSN), либо Home-CSN (домашней VSP), либо Visited-CSN (посещаемой CSN). Присваивание IP-адреса абоненту SS/MS выполняется сетью предоставления услуг доступа WiMAX (ASN), которая называется сетью доступа.
В соответствии с изобретением, присваивание IP-адреса выполняется с использованием ретранслятора DHCP в ASN. Таким образом, предполагается, что сервер DHCP размещен в CSN, а ASN обеспечивает ретранслятор DHCP. Цель ретранслятора DHCP заключается в том, чтобы ретранслировать сообщения DHCP от абонента SS/MS в сервер DHCP в CSN. Во время аутентификации абонента CSN обеспечивает ASN IP-адресом сервера DHCP в CSN. Этот IP-адрес позже используется ретранслятором DHCP для того, чтобы ретранслировать сообщения DHCP от терминала в надлежащий сервер DHCP. Поскольку CSN и ASN могут быть размещены в разных подсетях, которые связаны через неизвестную сеть IP, например, общедоступный Интернет. В результате данные, обмениваемые между ретранслятором DHCP и сервером DHCP, могут проходить через незащищенную инфраструктуру IP (см. узлы R3 и R5).
Чтобы избегать ситуации, когда сервер DHCP может подвергаться атаке, изобретение предлагает использовать ключи шифрования, в дальнейшем называемые ключами DHCP, для защиты сообщений DHCP между ретранслятором DHCP и сервером DHCP. Подобный подход уже используется стандартами WiMAX Forum NWG для того, чтобы генерировать HA-RK, используемый для аутентификации передачи сигналов IP мобильной связи между HA и FA. Фиг.2 иллюстрирует ключевую иерархию WiMAX с различными ключами, и как они выводятся. Пояснение этой известной иллюстрации может быть найдено в RFC 4030. Ключи DHCP генерируются из основного ключа, который упоминается как DHCP-RK (корневой ключ). Ключ DHCP-RK генерируется ААА-сервером, который размещен в CSN. Ключ транспортируется в ретранслятор DHCP и сервер DHCP, используя протокол ААА. Из DHCP-RK выводятся дополнительные ключи DHCP, которые являются определенными для каждой пары ретранслятора DHCP/сервера DHCP, и эти ключи DHCP используются для защиты сообщений DHCP, обмениваемых между ретранслятором (ретрансляторами) DHCP и сервером DHCP.
DHCP-RK и ключи DHCP, выводимые из него, не зависят от главного ключа сеанса связи (MSK) или расширенного главного ключа сеанса связи (EMSK), генерируемого в результате определенной аутентификации EAP. Следовательно, DHCP-RK и выводимые ключи DHCP связаны не с индивидуальным пользователем или сеансами аутентификации, а с определенными сервером DHCP и с парами ретранслятора DHCP/сервера DHCP. DHCP-RK будет генерироваться только по требованию, но не для каждой имеющей место аутентификации (повторной аутентификации) EAP. Тем не менее, ключ DHCP-RK наряду с идентификатором ключа и продолжительностями времени существования поставляются в аутентификатор во время аутентификации доступа в сеть абонента. Время существования и идентификатор ключа, генерируемые сервером DHCP и идентифицирующие определенный DHCP-RK, управляются ААА-сервером. Обязанностью ААА-сервера является поставлять новый DHCP-RK в аутентификатор до истечения действия DHCP-RK.
DHCP-RK генерируется ААА-сервером посредством назначения сервера DHCP для абонента, выполняющего аутентификацию. Для каждого сервера DHCP генерируется отличающийся DHCP-RK. DHCP-RK может генерироваться ААА-сервером следующим образом:
DHCP-RK = HMAC - SHA1 (RAND, "КОРНЕВОЙ КЛЮЧ ПРИЛОЖЕНИЯ DHCP").
Таким образом, RAND - случайное значение, генерируемое ААА-сервером. ААА-сервер также сопоставляет каждый DHCP-RK с уникальным идентификатором ключа. Идентификатор ключа определяется в RFC 4030. Идентификатор ключа является уникальным в пределах единственного сервера DHCP. В случае, если в одно и то же время существуют несколько ключей DHCP-RK для единственного сервера DHCP, они должны иметь различные идентификаторы ключей. Ключи DHCP-RK, принадлежащие различным серверам DHCP, могут использовать один и тот же идентификатор ключа. ААА-сервер поставляет DHCP-RK в аутентификатор EAP и сервер DHCP.
Аутентификатор EAP из DHCP-RK генерирует ключ DHCP для определенной пары ретранслятора DHCP/сервера DHCP, если он запрашивается определенным ретранслятором DHCP. Ключ DHCP, определенный для ретранслятора DHCP, который также называется шлюзом сети прикладных программ ASN-GW, может быть получен следующим образом:
DHCP-ключ = HMAC SHA1 (DHCP-RK, "DHCP AUTH", DHC-Ретранслятор-IP, DHC-Сервер-IP).
Этот ключ выводится аутентификатором EAP и сервером DHCP. Он передается аутентификатором EAP в ретранслятор DHCP.
В любой момент времени ААА-сервер может иметь несколько допустимых ключей DHCP-RK, определенных для единственного сервера DHCP. Эти ключи DHCP-RK должны иметь разные идентификаторы ключей и могут иметь разные продолжительности времени существования. Это необходимо для того, чтобы обеспечивать возможность бесшовного обновления DHCP-RK, давая возможность сосуществовать и старому, и новому DHCP-RK, и использовать их одновременно в течение некоторого периода времени.
Ключи, генерируемые ААА-сервером, могут транспортироваться в сервер DHCP и аутентификатор с использованием протокола RADIUS. Ключи DHCP, генерируемые аутентификатором (выводимые из DHCP-RK), транспортируются в ретранслятор DHCP, например, через определенную WiMAX передачу сигналов R4. Ключи, генерируемые сервером DHCP, никогда не транспортируются за пределы сервера DHCP.
Рассмотрим фиг.3, на которой показано распределение ключей DHCP для случая, когда ретранслятор DHCP размещен совместно с аутентификатором EAP.
Как описано выше, аутентификатор и ретранслятор DHCP размещены в ASN, тогда как ААА-сервер, сервер EAP и держатель ключей вместе с сервером DHCP размещены в CSN. Абонент для телекоммуникационной сети изображен символом MN.
Распределение ключей может выполняться во время процесса аутентификации абонента MN в телекоммуникационной сети. Поэтому абонент MN посылает сообщение запроса в шлюз сети доступа ASN-GW, действующий как аутентификатор, и ретранслятор DHCP. Шлюз сети доступа передает сообщение запроса доступа в CSN, главным образом в ААА-сервер. Аутентификатор принимает адрес сервера DHCP в сообщении принятия доступа в соответствии с протоколом RADIUS в результате успешной аутентификации абонента. В случае, если в ААА-сервере имеется несколько ключей DHCP-RK, связанных с сервером DHCP, ААА-сервер должен включить в сообщение принятия доступа DHCP-RK с самым большим остающимся временем существования. Помимо DHCP-RK, сообщение принятия доступа содержит также время существования и идентификатор ключа DHCP-RK, который сервером DHCP был обеспечен последним. DHCP-RK транспортируется через RADIUS и шифруется, например, используя способ, определенный в разделе 3.5 RFC-2868. Ключи, генерируемые ААА-сервером, сохраняются в держателе ключей в аутентификаторе, находящемся в ASN (не показано).
Во время процедур DHCP ретранслятор DHCP получает выводимый ключ DHCP от держателя ключей в аутентификаторе. Держатель ключей выводит ключ DHCP, определенный для запрашивающего ретранслятора DHCP, из DHCP-RK и поставляет выведенный ключ, его время существования и идентификатор ключа, связанный с DHCP-RK, в ретранслятор DHCP. Ретранслятор DHCP использует принятый ключ DHCP для вычисления дополнительной опции аутентификации и включает эту дополнительную опцию в сообщение DHCP. Когда сервер DHCP принимает сообщение с дополнительной опцией аутентификации, он отыскивает соответствующий ключ DHCP в своей локальной сверхоперативной памяти с помощью адреса ретранслятора DHCP и принятого идентификатора ключа. Если соответствующий ключ не найден, сервер DHCP выводит новый ключ DHCP, определенный для этого ретранслятора DHCP, из DHCP-RK. Если в сервере DHCP имеется несколько ключей DHCP-RK, он использует принятый идентификатор ключа для того, чтобы выбрать правильный DHCP-RK. Если не найден DHCP-RK, который связан с принятым идентификатором ключа, сервер DHCP приобретает DHCP-RK у ААА-сервера. Это может быть выполнено таким же способом, каким собственное исполнительное устройство приобретает корневой ключ собственного исполнительного устройства. Сервер DHCP должен включить принятый идентификатор ключа в сообщение запроса доступа. Это даст возможность ААА-серверу разместить правильный DHCP-RK в случае, если в ААА-сервере имеется несколько ключей DHCP-RK для этого конкретного сервера DHCP.
Фиг.4 описывает распределение ключей DHCP в случае, когда ретранслятор DHCP и аутентификатор не размещены совместно. Когда ретранслятор DHCP перехватывает сообщение DHCP от абонента, он должен обеспечить его дополнительной опцией аутентификации, как установлено в RFC 4030. Если в ретрансляторе DHCP не имеется ключа, соответствующего серверу DHCP, ретранслятор DHCP может запросить ключ у аутентификатора, посылая сообщение запроса контекста с пустым TLV ключа DHC. Аутентификатор выведет необходимый ключ и поставит выведенный ключ, его время существования и идентификатор связанного ключа в ретранслятор DHCP в сообщении запроса контекста. Приобретя ключ DHCP, ретранслятор DHCP продолжает действовать, как описано выше в варианте осуществления фиг.3, когда ретранслятор DHCP и аутентификатор размещены совместно.

Claims (20)

1. Способ передачи сообщения DHCP между сервером DHCP телекоммуникационной сети и устройством абонента межсетевого протокола (IP) (SS/MS; MN), связанным с телекоммуникационной сетью, в котором к сообщению DHCP добавляется информация, защищенная с помощью ключа шифрования, отличающийся тем, что ключ шифрования выводится из основного ключа, обеспечиваемого дополнительным сервером телекоммуникационной сети, при этом основной ключ является определенным ключом для сервера DHCP.
2. Способ по п.1, отличающийся тем, что сообщение DHCP, генерируемое устройством абонента, перехватывается ретранслятором DHCP, размещенным в телекоммуникационной сети, при этом добавляется информация, зашифрованная с помощью ключа шифрования.
3. Способ по любому из пп.1 или 2, отличающийся тем, что ключ шифрования генерируется для определенной пары сервера DHCP и ретранслятора DHCP с использованием основного ключа, определенного для сервера DHCP.
4. Способ по п.1, отличающийся тем, что дополнительный сервер является ААА-сервером домашней сети абонента, и тем, что основной ключ и идентификатор связанного ключа, где связанный ключ соответственно идентифицирует основной ключ, пересылаются от ААА-сервера домашней сети абонента, предпочтительно в сообщении запроса доступа, в сеть доступа (ASN), обслуживающую абонента (SS/MS; MN).
5. Способ по любому из пп.1 или 4, отличающийся тем, что ключ шифрования (ключ DHCP) выводится конкретно для каждого шлюза сети доступа (ASN-GW) в соответствующей сети предоставления услуг доступа (ASN) и действующего как ретранслятор DHCP для устройства абонента (SS/MS; MN).
6. Способ по любому из пп.1, 2 или 4, отличающийся тем, что пересылают идентификатор ключа и значения выявлений воспроизведения от старого ретранслятора DHCP к новому ретранслятору DHCP в виде части контекста через определенные служебные сообщения, главным образом WiMAX.
7. Способ по любому из пп.1, 2 или 4, отличающийся тем, что когда сервер DHCP в домашней сети абонента принимает сообщение DHCP от ретранслятора DHCP сети доступа, для которого все еще не имеется ключа шифрования, но дополнительная опция аутентификации указывает идентификатор ключа, уже известный серверу DHCP, сервер DHCP генерирует новый ключ шифрования из известного основного ключа, связанного с принятым идентификатором ключа.
8. Способ по любому из пп.1, 2 или 4, отличающийся тем, что телекоммуникационная сеть является сетью, соответствующей стандарту WiMAX.
9. Компонент телекоммуникационной сети для передачи сообщения DHCP между сервером DHCP телекоммуникационной сети и устройством абонента межсетевого протокола (IP) (SS/MS; MN), связанного с телекоммуникационной сетью, в котором к сообщению DHCP добавляется информация, защищенная с помощью ключа шифрования, отличающийся тем, что ключ шифрования выводится компонентом телекоммуникационной сети из основного ключа, обеспечиваемого дополнительным сервером телекоммуникационной сети, и тем, что основной ключ является определенным ключом для сервера DHCP.
10. Компонент телекоммуникационной сети по п.9, отличающийся тем, что ключ шифрования генерируется для пары сервера DHCP и ретранслятора DHCP с использованием основного ключа, определенного для сервера DHCP.
11. Компонент телекоммуникационной сети по п.9 или 10, отличающийся тем, что дополнительный сервер является ААА-сервером домашней сети абонента, и тем, что основной ключ и идентификатор связанного ключа, где связанный ключ соответственно идентифицирует основной ключ, пересылаются от ААА-сервера, предпочтительно в сообщении запроса доступа, в компонент телекоммуникационной сети.
12. Компонент телекоммуникационной сети по любому из пп.9 или 10, отличающийся тем, что компонент телекоммуникационной сети представляет собой сервер DHCP.
13. Компонент телекоммуникационной сети по п.12, отличающийся тем, что когда сервер DHCP принимает сообщение DHCP, для которого все еще не имеется ключа шифрования, но дополнительная опция аутентификации, включенная в сообщение DHCP, указывает идентификатор ключа, уже известный серверу DHCP, сервер DHCP генерирует новый ключ шифрования из известного основного ключа, связанного с принятым идентификатором ключа.
14. Компонент телекоммуникационной сети по любому из пп.9 ил 10, отличающийся тем, что сообщение DHCP, генерируемое устройством абонента, перехватывается компонентом телекоммуникационной сети, при этом добавляется информация, зашифрованная с помощью ключа шифрования.
15. Компонент телекоммуникационной сети по любому из пп.9 или 10, отличающийся тем, что компонент телекоммуникационной сети представляет собой, по меньшей мере, один из ретранслятора DHCP и компонента аутентификатора сети доступа.
16. Компонент телекоммуникационной сети по п.14, отличающийся тем, что компонент телекоммуникационной сети представляет собой, по меньшей мере, один из ретранслятора DHCP и компонента аутентификатора сети доступа.
17. Компонент телекоммуникационной сети по любому из пп.9 или 10, отличающийся тем, что компонент телекоммуникационной сети является шлюзом сети доступа, а ключ шифрования выводится конкретно для шлюза сети доступа с использованием основного ключа в соответствующей сети предоставления услуг доступа, и действующим, как ретранслятор DHCP для сообщения DHCP.
18. Компонент телекоммуникационной сети по п.14, отличающийся тем, что компонент телекоммуникационной сети является шлюзом сети доступа, а ключ шифрования выводится конкретно для шлюза сети доступа с использованием основного ключа в соответствующей сети предоставления услуг доступа, и действующим, как ретранслятор DHCP для сообщения DHCP.
19. Компонент телекоммуникационной сети по п.14, отличающийся тем, что поддерживают пересылку идентификатора ключа и значения выявлений воспроизведения от старого компонента телекоммуникационной сети, включающего в себя функциональные возможности ретранслятора DHCP, в новый компонент телекоммуникационной сети, включающий в себя функциональные возможности ретранслятора DRCP, в виде части контекста через определенные служебные сообщения, главным образом WiMAX.
20. Компонент телекоммуникационной сети по любому из пп.9-10, отличающийся тем, что телекоммуникационная сеть является сетью, соответствующей стандарту WiMAX.
RU2009118395/08A 2006-10-16 2007-10-15 Способ передачи сообщений dhcp RU2447603C2 (ru)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP06021659.5 2006-10-16
EP06021659 2006-10-16
EP07007443.0 2007-04-11
EP07007443A EP1914960B1 (en) 2006-10-16 2007-04-11 Method for transmission of DHCP messages

Publications (2)

Publication Number Publication Date
RU2009118395A RU2009118395A (ru) 2010-11-27
RU2447603C2 true RU2447603C2 (ru) 2012-04-10

Family

ID=39202048

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2009118395/08A RU2447603C2 (ru) 2006-10-16 2007-10-15 Способ передачи сообщений dhcp

Country Status (4)

Country Link
US (1) US8275987B2 (ru)
EP (1) EP1914960B1 (ru)
RU (1) RU2447603C2 (ru)
WO (1) WO2008046813A1 (ru)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1914960B1 (en) * 2006-10-16 2013-01-09 Nokia Siemens Networks GmbH & Co. KG Method for transmission of DHCP messages
US20090106831A1 (en) * 2007-10-18 2009-04-23 Yingzhe Wu IPsec GRE TUNNEL IN SPLIT ASN-CSN SCENARIO
EP2053886A3 (en) * 2007-10-26 2015-03-25 Hitachi, Ltd. Communication system and gateway apparatus
JP5210798B2 (ja) * 2008-10-30 2013-06-12 日本無線株式会社 ＷｉＭＡＸ通信システム
CN102056159B (zh) * 2009-11-03 2014-04-02 华为技术有限公司 一种中继系统的安全密钥获取方法、装置
US8819191B2 (en) * 2011-07-12 2014-08-26 Cisco Technology, Inc. Efficient use of dynamic host configuration protocol in low power and lossy networks

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2273107C2 (ru) * 2001-10-24 2006-03-27 Закрытое акционерное общество "ПлатоФон" Способ, система и компьютерное устройство для предоставления услуг связи между ресурсами в сетях связи и интернет с целью проведения транзакций
WO2007051787A1 (de) * 2005-11-04 2007-05-10 Siemens Aktiengesellschaft Verfahren und server zum bereitstellen eines mobilitätsschlüssels

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1241368C (zh) * 2000-12-06 2006-02-08 日本电气株式会社 假想私设网
US7317708B2 (en) * 2004-10-07 2008-01-08 Samsung Electronics Co., Ltd. Apparatus and method for providing indoor and outdoor wireless access in broadband wireless access communication system
DE102006004868B4 (de) * 2005-11-04 2010-06-02 Siemens Ag Verfahren und Server zum Bereitstellen eines Mobilitätsschlüssels
KR100950653B1 (ko) * 2006-02-28 2010-04-01 삼성전자주식회사 이종 통신 시스템들에서 데이터 송수신 방법 및 시스템
DE102006038037A1 (de) * 2006-08-14 2008-02-21 Siemens Ag Verfahren und System zum Bereitstellen eines zugangsspezifischen Schlüssels
EP1914960B1 (en) * 2006-10-16 2013-01-09 Nokia Siemens Networks GmbH & Co. KG Method for transmission of DHCP messages

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2273107C2 (ru) * 2001-10-24 2006-03-27 Закрытое акционерное общество "ПлатоФон" Способ, система и компьютерное устройство для предоставления услуг связи между ресурсами в сетях связи и интернет с целью проведения транзакций
WO2007051787A1 (de) * 2005-11-04 2007-05-10 Siemens Aktiengesellschaft Verfahren und server zum bereitstellen eines mobilitätsschlüssels

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
H.Tschofenig Siemens, A.Yegin Samsung, D.Forsberg Nokia: «Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication draft-yegin-eap-boot-rfC3118-02.txt» IETF STANDARD-WORKING-DRAFT, no.2, 2006.02. *

Also Published As

Publication number Publication date
EP1914960A1 (en) 2008-04-23
WO2008046813A1 (en) 2008-04-24
US20100191963A1 (en) 2010-07-29
RU2009118395A (ru) 2010-11-27
EP1914960B1 (en) 2013-01-09
US8275987B2 (en) 2012-09-25

Similar Documents

Publication Publication Date Title
US7298847B2 (en) Secure key distribution protocol in AAA for mobile IP
KR101374810B1 (ko) 가상 가입자 식별 모듈
CN101160924B (zh) 在通信系统中分发证书的方法
US9197615B2 (en) Method and system for providing access-specific key
TWI293844B (en) A system and method for performing application layer service authentication and providing secure access to an application server
JP4913909B2 (ja) モバイルｉｐネットワークにおけるルート最適化
EP2506491B1 (en) Encryption information transmission terminal
US20060059344A1 (en) Service authentication
CN102668497B (zh) 允许电信网络中的安全通信而免于服务的拒绝(DoS)和浸灌攻击的方法和装置
CN101675644A (zh) 无线通信网络中的用户概况、策略、及pmip密钥分发
JP2004241976A (ja) 移動通信ネットワークシステムおよび移動端末認証方法
JP2006086907A (ja) 設定情報配布装置、方法、プログラム、媒体、及び設定情報受信プログラム
WO2011041962A1 (zh) 一种支持合法监听的端到端会话密钥协商方法和系统
RU2447603C2 (ru) Способ передачи сообщений dhcp
CN107005562B (zh) 网络中的设备的调试
JP2000115161A (ja) 移動体匿名性を保護する方法
CN101569160B (zh) 用于传输dhcp消息的方法
KR101821794B1 (ko) 보안 ip 통신 서비스를 제공하기 위한 장치, 방법 및 통신 시스템
EP1562340A1 (en) Method and apparatus for establishing a temporary secure connection between a mobile network node and an access network node during a data transmission handover
KR20140131764A (ko) 무선 통신 시스템에서 이동 단말의 접속 인증 방법 및 장치
Abdelkader et al. A novel advanced identity management scheme for seamless handoff in 4G wireless networks
JP2006191429A (ja) 集合型宅内ネットワークにおける認証方法及びシステム
CN1996838A (zh) 一种多主机WiMAX系统中的AAA认证优化方法
KR102345093B1 (ko) 무선 인터넷의 보안 세션 제어 시스템 및 보안 세션 제어 방법
CN100512105C (zh) 一种柔性ip网络技术体系的安全密钥管理方法

Legal Events

Date Code Title Description
MM4A The patent is invalid due to non-payment of fees

Effective date: 20131016