ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Journal influence

Higher Attestation Commission (VAK) - К1 quartile
Russian Science Citation Index (RSCI)

Bookmark

Next issue

4
Publication date:
09 December 2024

Users group access rights in eduroam – federated user identity management system For research and educational networks

The article was published in issue no. № 4, 2012 [ pp. 10-18 ]
Abstract:The paper describes a federated identity management infrastructure based on eduroam. This technology enables secure authentication using single netid for network and resources access in eduroam federation. Major protocols and technologies for transparent user authentication are covered. A way of authorization, based on membership in institutional groups and individual user membership is proposed. For user authentication a service provider sends an authentication request contained the encrypted user name and password to user's institute RADIUS server (identity provider). Identity provider is determined by the domain user name/ The authentication request is passed through th eduroam hierarchy of proxy RADIUS servers. If the service provider provides special access for a certain group of users, it also sends a request to group identity RADIUS-server. A request passes through a hierarchy of group RADIUS servers for group membership checking. Eduroam federation and group RADIUS servers hierarchies are based on the domain name system. The implementation of these mechanisms requires a slight modification of service provider RADIUS server for group support and do not require changes of the identity provider and eduroam federations RADIUS servers. Group support is fully compatible with the existing eduroam infrastucture, the both types of RADIUS servers with and without group support can operate simultaneously.
Аннотация:Описывается реализация федеративного контроля доступа для научных сетей на основе технологии eduroam. Технология предоставляет пользователям возможность безопасной аутентификации для доступа к сети и использования сетевых ресурсов в любой сети федерации eduroam с использованием единственного набора учетных данных. Рассматриваются основные технологии и протоколы, используемые для обеспечения прозрачной аутентификации пользователей. Авторами впервые предложен механизм прав доступа на основе групп институтов и пользователей. Информация о группах хранится на групповых RADIUS-серверах в виде списка институтов или списка пользователей. Для аутентификации пользователя в eduroam сервис-провайдер передает запрос на аутентификацию, содержащий имя и пароль пользователя в зашифрованном виде, RADIUS-серверу идентификации института пользователя. Сервер идентификации определяется по доменному имени пользователя, запрос передается через иерархическую систему прокси-серверов RADIUS. Если сервис-провайдер обеспечивает специальный доступ для пользователей некоторой группы, он также направляет на RADIUS-сервер группы запрос о принадлежности пользователя этой группе. Запрос передается через иерархическую систему групповых серверов RADIUS. Иерархия прокси-серверов RADIUS федерации eduroam и групповых серверов основывается на доменной системе имен. Реализация описанных механизмов требует незначительной модификации RADIUS-сервера сервис-провайдера для поддержки групп и не требует внесения изменений в RADIUS-серверы провайдеров идентификации и прокси- серверы системы eduroam. Поддержка групп полностью совместима с существующей системой eduroam, в одной системе могут одновременно функционировать серверы RADIUS сервис-провайдера с поддержкой групп и без поддержки.
Authors: Ovsyannikov, A.P. (ovsyannikov@jscc.ru) - Joint Supercomputer Center of RAS (Leading Researcher), Moscow, Russia, (tat@jscc.ru) - , Russia, (velegrin@jscc.ru) - , Russia
Keywords: federation, authentication, authorization, network of science and education, scientific Telecommunications, radius, network access, wireless network, wifi, eduroam
Page views: 13453
Print version
Full issue in PDF (9.63Mb)
Download the cover in PDF (1.26Мб)

Font size:       Font:

Тенденция к расширению и углублению сотрудничества между научными центрами в России и за рубежом приводит к необходимости объединения вычислительных и сетевых ресурсов сотрудничающих организаций. Для такого объединения необходима интеграция как на уровне сетевой инфраструктуры, так и на административном уровне: установление доверительных отношений, унификация правил доступа к разделяемым ресурсам и так далее. В числе наиболее важных вопросов объединения сетевых ресурсов – обеспечение контроля доступа и интеграция систем аутентификации и авторизации пользователей. Одним из подходов к решению данной проблемы является построение федеративной инфраструктуры управления идентификацией пользователей. Федеративный доступ позволяет пользователям использовать один набор учетных данных для доступа к ресурсам сетей, установивших доверительные отношения, согласовавших правила доступа к ресурсам и входящих в ассоциацию безопасности, называемую федерацией [1]. В качестве примера федеративного доступа к сетевым ресурсам можно привести проекты европейской научно-образова­тельной сети GEANT eduGAIN и eduroam.

Eduroam (Educational Roaming) представляет собой распределенную инфраструктуру доступа к сети для мобильных пользователей. Данная технология позволяет использовать одно имя пользователя и пароль как в организации постоянного пребывания пользователя, так и в любой другой организации-члене федерации eduroam. В настоящее время в федерацию eduroam входят операторы научных и образовательных сетей 54 стран, включая большинство европейских стран, страны Юго-Восточной Азии, Южной Америки, Австралию и отдельные университеты США.

Технология eduroam

Основными компонентами архитектуры eduro­am являются следующие:

–      сервер доступа к сети (СДС) – коммутатор или беспроводная точка доступа, обеспечивающая доступ клиентов к сети;

–      клиент – конечное устройство, обеспечивающее аутентификацию и доступ к сети на стороне пользователя;

–      сервер аутентификации (СА) – програм- мно-аппаратный комплекс, осуществляющий аутентификацию и авторизацию клиентов и динамическую конфигурацию СДС; СА хранит информацию об учетных данных пользователей; в eduroam в качестве СА используется RADIUS [2];

–      IEEE 802.1X [3] – стандарт контроля доступа на основе порта;

–      IEEE 802.1Q [4] – стандарт, описывающий передачу информации о принадлежности к VLAN.

IEEE 802.1X

Стандарт IEEE 802.1X является протоколом контроля доступа на основе порта пользователя. Устройство, поддерживающее данный стандарт, предоставляет доступ к сети только клиентам, успешно прошедшим аутентификацию и авторизацию. Для аутентификации пользователей используется расширяемый протокол аутентификации (Extensible Authentication Protocol – EAP) [5]. Аутентификационные данные передаются по локальной сети (EAP over LAN – EAPoL) и инкапсулированными в протокол RADIUS (рис. 1). При этом СДС лишь передает сообщения клиента и СА и предоставляет либо запрещает доступ к сети на основе ответа СА. 802.1Х дает возможность использовать различные методы аутентификации на основе EAP, что позволяет каждой сети-члену федерации самостоятельно выбирать наиболее удобные для данной сети методы аутентификации независимо от других членов федерации, в частности, методы с взаимной аутентификацией клиента и сервера аутентификации. Такие методы позволяют пользователю удостовериться в подлинности СА перед передачей СА конфиденциальных данных, таких как имя пользователя и пароль доступа. К ним относятся EAP-TLS, EAP-TTLS, EAP-PEAP. При использовании любого из этих методов клиент может проверить полученный от СА сертификат с помощью предустановленной копии открытого ключа удостоверяющего центра и, возможно, списка отзыва сертификатов.

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

IEEE 802.1Q

Подпись:  
Рис. 1. Уровни EAP-аутентификации
Стандарт IEEE 802.1Q определяет способ построения виртуальных локальных сетей (Virtual LAN, VLAN). В случае, когда коммутатор поддерживает IEEE 802.1Q, можно динамически назначать клиентам различные VLAN. Это особенно актуально в рамках федеративного контроля доступа, так как позволяет автоматически настраивать различные уровни доступа для различных классов пользователей. Например, классу пользователей-сотрудников может предоставляться полный доступ к ресурсам, классу студентов – ограниченный доступ, классу гостевых пользователей может быть запрещен доступ к внутренним ресурсам сети. При использовании RADIUS и IEEE 802.1X можно определять класс доступа пользователя и назначать им соответствующий VLAN. Для этого СА передает СДС пары атрибут–значение, на основании которых СДС назначает порту тот или иной VLAN.

Серверы аутентификации

Серверы аутентификации eduroam используют протокол RADIUS и выполняют аутентификацию, авторизацию клиентов и настройку СДС. При этом клиент использует EAPoL для подключения к СДС, который инкапсулирует полученные от клиента данные EAP в RADIUS и передает СА. В свою очередь СА проводит аутентификацию клиента и одобряет или отклоняет запрос. На основе решения СА СДС позволяет или запрещает доступ к сети. Ответ СА также может содержать данные о разрешенном клиенту уровне доступа. СА может поддерживать различные механизмы аутентификации. В частности, для хранения учетных данных пользователя могут использоваться текстовые файлы, реляционные базы данных, удостоверяющие центры или базы данных, использующие протокол LDAP [6] (Novel, et al.). Это позволяет различным членам федерации выбирать наиболее подходящий им способ хранения учетных данных пользователей.

Помимо передачи аутентификационных данных, протокол RADIUS предусматривает возможность передачи набора атрибутов [7], например МАС-адрес клиента. Эти атрибуты могут использоваться для мониторинга, сбора статистики и т.д. Количество пар атрибут–значение ограничено 256, и назначение новых атрибутов требует согласования со стандартизующими организациями. Существует механизм расширения пространства атрибутов путем передачи Vendor-Specific атрибута, однако на настоящий момент нет стандартного метода шифрования Vendor-Specific атрибута, поэтому использование этого механизма нежелательно.

СА RADIUS образуют фундамент авторизационной инфраструктуры eduroam (рис. 2). При этом СА может выступать как RADIUS-сервер федеративного уровня (Federal Level RADIUS Server, FLRS), провайдер сервиса доступа к сети (Service Provi­der, SP) или сервер идентификации пользователей (Identity Provider, IdP).

RADIUS-сервер федеративного уровня

FLRS является основой инфраструктуры eduroam в своей федерации. Он содержит список СА всех членов этой федерации и выполняет маршрутизацию запросов, при этом запросы к СА, находящимся в одной федерации с FLRS, направляются соответствующим СА, а запросы к СА, находящимся за пределами федерации, направляются на RADIUS-серверы конфедерации.

Благодаря тому, что RADIUS-серверы могут перенаправлять запросы без чтения их содержимого, пользователь может использовать одни и те же настройки аутентификации (имя пользователя, пароль и метод аутентификации) как в своей, так и в любой другой организации, участвующей в eduroam. При этом, если используется один из методов аутентификации, обеспечивающий шифрование (EAP-TLS, EAP-TTLS, EAP-PEAP), ни FLRS, ни любой другой RADIUS-сер­вер в иерархии eduroam не получает доступа к конфиденциальной информации о пароле и в некоторых случаях об имени пользователя.

Провайдер сервиса доступа к сети

SP осуществляет связь и маршрутизацию запросов между СДС и вышестоящими серверами RADIUS. Получая от СДС инкапсулированный в протокол RADIUS запрос на доступ к сети, SP перенаправляет его вышестоящему серверу RADIUS (обычно FLRS) и ожидает ответа. В случае успешной аутентификации пользователя SP позволяет СДС открыть пользователю доступ к сети и определяет, какой VLAN назначить соответствующему порту.

Сервер идентификации пользователей

Подпись:  
Рис. 2. Иерархия RADIUS-серверов
Задача IdP сводится к хранению учетных данных пользователей и проверке запросов на аутентификацию. Стоит отметить, что роли SP и IdP можно объединить в рамках одной программно-аппаратной реализации в том случае, если организация одновременно предоставляет доступ к своей сети и позволяет своим сотрудникам пользоваться доступом к ней в других организациях-членах конфедерации eduroam.

Имя пользователя в eduroam состоит из двух частей: префикса, являющегося именем пользователя в его домашней организации, формат которого оставлен на усмотрение этой организации, и отделенного символом @ суффикса, называемого realm пользователя и совпадающего с доменным именем организации в терминах системы доменных имен DNS. Например, пользователь из МСЦ РАН может иметь имя user@jscc.ru. Маршрутизация запросов производится на основании realm пользователя. Так, в случае, если пользователь user@jscc.ru отправляет запрос, находясь за пределами Российской Федерации, он будет направлен SP, к которому подключается пользователь, далее FLRS, которому принадлежит данный SP, далее через серверы конфедерации российскому FLRS и, наконец, IdP домашней организации пользователя (в данном примере МСЦ РАН). В случае, если пользователь подключается к SP, принадлежащему к той же федерации, что и IdP пользователя, запрос будет направлен через FLRS соответствующей федерации к IdP пользователя.

Права доступа на основе групп институтов  и серверов

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

–      класс локальных пользователей, принадлежащих к данному члену федерации; к нему относятся пользователи, запросы на авторизацию которых получены не от FLRS;

–      класс пользователей из национальной федерации; в него входят пользователи, чьи запросы не направлялись на RADIUS-серверы конфедерации;

–      класс всех пользователей.

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

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

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

Если решение о назначении привилегий пользователю принимается на основе realm пользователя, это приводит к ряду сложностей. Групповой сервис-провайдер должен иметь список realm всех участников группы. Присоединение к группе нового института требует обновления файлов настройки у всех сервис-провайдеров группы. Большое число институтов в группе может сделать настройку RADIUS у сервис-провайдера трудоемкой, и в конечном итоге требуется автоматизация распространения списка участников группы. Проблемой также является необходимость включения в группу realm, если в проекте группы участвует не весь институт/университет, а некоторые его подразделения (лаборатории, кафедры, факультеты) или даже отдельные сотрудники. При этом сервис-провайдер будет вынужден предоставить специальный доступ пользователям, которым он не нужен.

Персональное назначение привилегий может быть реализовано с использованием атрибутов, получаемых от провайдера идентификации IdP. В этом случае в локальной базе, используемой для аутентификации пользователей института, должна храниться информация о принадлежности пользователя к той или иной группе (проекту). Это достаточно сложно: локальная база пользователей может не поддерживать требуемые поля, сотрудник института может участвовать во множестве проектов, поддержание актуальности информации о принадлежности к группам требует согласованной работы администраторов и т.д. Кроме того, количество атрибутов протокола RADIUS ограничено, а механизмы расширения пространства атрибутов не поддерживают шифрование новых атрибутов и их значений, что может привести к утечке или подмене конфиденциальных данных о принадлежности пользователя к группе.

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

Предлагается схема хранения информации о группах на основе групповых RADIUS-серверов, хранящих списки входящих в группу институтов (а возможно, и персональных учетных записей). На рисунках 3 и 4 приведены основные сценарии аутентификации с использованием RADIUS-сер­вера группы.

В первом варианте RADIUS-сервер группы (на рисунке обозначен как GRS) выступает в качестве промежуточного прокси, включенного в систему eduroam. RADIUS-сервер сервис-провайдера получает запрос на аутентификацию пользователя от сетевого оборудования и перенаправляет его на известный ему RADIUS-сервер группы. RADIUS-сервер группы проверяет принадлежность имени пользователя (включая домен user@realm) или его домена (@realm) списку группы. Если имя пользователя или домен отсутствует в списке, возвращается Reject. Если присутствует, запрос переправляется на FLRS в соответствии со стандартной процедурой eduroam. Если сервис-про­вайдер проверяет участие пользователя в нескольких группах, RADIUS-сервер SP должен направить запросы на аутентификацию RADIUS-серверам всех групп. Если пользователь участвует в нескольких группах, запросы будут продублированы на FLRS и сервер идентификации IdP по числу групп. Cер­вис-провайдер в запросе RADIUS-серверу группы должен указывать полное имя пользователя, преобразование для выделения домена (realm) из имени пользователя для запроса к FLRS выполняет RADIUS-сервер группы.

Во втором варианте RADIUS-сервер сервис-провайдПодпись:  Рис. 3. Сценарий аутентификации с использованием RADIUS-сервера группы Рис. 4. Сценарий аутентификации через FLRS и RADIUS-сервер группыера производит аутентификацию пользователя с использованием стандартной процедуры eduroam, направляя запрос на FLRS. Параллельно сервис-провайдер направляет запросы имени пользователя на все RADIUS-серверы групп, в которых он участвует. Такой запрос не содержит шифрованной части, направляемой FLRS. RADI­US-сервер группы возвращает Accept/Reject в зависимости от присутствия имени или домена пользователя в своей базе (списке членов группы). Решение о назначении привилегий сервис-провай­дер принимает в зависимости от успеха аутентификации пользователя в eduroam и ответов RADI­US-серверов групп. Если группы построены на учете организаций в целом (то есть не используют персональные учетные записи), сервис-провайдер не обязан включать имя пользователя в запрос, то есть использовать лишь @realm (anonymous@re­alm). И в первом, и во втором вариантах каждый сервис-провайдер должен знать имена RADIUS-серверов групп, в которых он участвует, их разделяемые ключи или сертификаты для шифрования запросов. Это требование можно исключить, если предусмотреть механизм направления запросов к RADIUS-серверам групп через некоторый прокси-RADIUS-сервер верхнего уровня, обслуживающий группы (GFLRS), в соответствии с общей логикой eduroam. GFLRS должен различать группы, это можно реализовать, используя доменные имена. Определим домен верхнего уровня, в котором в качестве поддоменов будут обозначены группы, причем для этой цели можно использовать любой реальный домен, например eduroam.ru. Примеры доменов групп: ras.eduroam.ru – РАН, lhc.edu­roam.ru – участники экспериментов БАК. RADI­US-сервер группы получает стандартное имя в домене группы, например gradius.lhc.eduroam.ru. Домены групп могут содержать поддомены и т.д., образуя иерархическую структуру. Каждый поддомен обслуживается соответствующим RADIUS-сервером (рис. 5).

Подпись:  Рис. 5. Иерархическая структура доменов группыДля аутентификации пользователя user@realm сервис-провайдер использует стандартную процедуру, направляя запрос на FLRS. Для определения принадлежности к группе сервис-провайдер направляет к GFLRS запрос, содержащий имя пользователя (user@realm), объединенное с доменным именем группы (group.edroam.tld) – user@realm. group.tld. Например, для пользователя direc­tor@jinr.ru и группы cms.lhc.eduroam.ru в запросе должно присутствовать имя director@jinr.ru.cms. lhc.eduroam.ru. GFLRS удаляет из имени пользователя в поступившем от сервис-провайдера запросе правую часть, совпадающую с доменом GFLRS, то есть director@jinr.ru.cms.lhc.eduroam.ru преобразуется в director@jinr.ru.cms.lhc. Верхний домен преобразованного таким образом имени пользователя используется для определения группы и ee RADIUS-сервера, на который будет перенаправлен запрос. В примере группой является lhc (lhc.eduroam.ru), запрос будет перенаправлен на ее RADIUS-сервер – gradius.lhc.eduroam.ru. Если запись о такой группе в GFLRS отсутствует (домен или RADIUS-сервер отсутствует в DNS), воз-вращается ответ Reject. На сервере gradius.lhc.edu­roam.edu из имени пользователя director@jinr.ru. cms.lhc будет удален домен lhc, и маршрутизация запроса будет произведена по домену cms по описанной выше процедуре для GFLRS. В конце концов запрос попадет на RADIUS-сервер группы с локальной базой. После удаления домена группы останется исходный user@realm (director@jinr.ru – в примере), который и используется для проверки принадлежности пользователя или института пользователя группе по локальной базе. Ответ переправляется обратно по цепочке прокси-RADI­US-северов сервис-провайдеру.

Групповой прокси-RADIUS-сервер (кроме GFLRS), помимо передачи запроса RADIUS-сер­веру поддомена, может использовать локальную базу. Тогда сначала проверяется возможность дальнейшей маршрутизации запроса на поддомен, в случае ее невозможности выполняется поиск имени пользователя или его домена в локальной базе, и ответ Accept/Reject возвращается по результатам поиска. Например, на GFLRS направлен запрос с именем researcher@itep.ru.lhc.edu­roam. edu. RADIUS-сервер gradius.lhc.eduroam.ru получает запрос от GFLRS с именем researcher@itep. ru.lhc, отбрасывает lhc и не находит домена ru в списке своих групп-поддоменов. Тогда выполняется поиск пользователя researcher@itep.ru и домена @itep.ru по локальной базе gradius.lhc.edu­roam.ru (предложенный механизм см. на рис. 4).

Подпись:  Рис. 6. Сценарий аутентификации через FLRS, RADIUS-серверы группы и институтаПринадлежность пользователя группе задается либо по домену института пользователя, либо по личной учетной записи. В университетах или крупных организациях, ведущих разноплановую научную деятельность, существует деление по подразделениям: факультетам, кафедрам, лабораториям. Возникает соблазн обозначить подразделения поддоменами домена института и использовать при задании группы в локальных базах RADIUS-серверов групп. Как правило, доменная часть в имени пользователя (user@realm) является доменом института и не содержит указания на подразделение, поэтому проверку принадлежности пользователя подразделению следует передать RADIUS-серверу его института. Запрос на проверку подразделения не включает данные, необходимые для его аутентификации, поэтому в общем случае этот RADIUS-сервер не совпадает с IdP. На рисунке 6 RADIUS-сервер института, проверяющий подразделение, обозначен как GRS института. Групповой RADIUS-сервер должен в локальной базе проверить не только имя user@realm и домен @realm, но и поддомены realm: @*.realm (например @lab.realm). В последнем случае соответствующему GRS направляется (возможно, через GFLRS) запрос, в котором имя пользователя уточнено найденным поддоменом, например user@lab.realm.

Итак, в статье приведено описание технологии eduroam, стандартов и протоколов, на которых она основана, и предложен способ расширенного определения прав доступа на основе объединений членов федерации. Реализация описанных механизмов требует незначительной модификации RADIUS-сервера сервис-провайдера и полностью совместима с существующей системой аутентификации и авторизации eduroam, не требует внесения изменений в работу IdP и FLRS. Возможно также модифицировать FLRS для выполнения функций GFLRS, а IdP – функций IRS. При этом система сможет функционировать в составе существующей системы eduroam, корректно обрабатывая и запросы на аутентификацию от сервис-провайдера провайдеру идентификации, и запросы на проверку групповой принадлежности. Недостатком данного решения является увеличение времени, требуемого для авторизации пользователя. Для его сокращения необходимы распараллеливание запросов к FLRS и GFLRS на стороне сервис-провайдера, ускорение поиска в локальной базе RADIUS-серверов групп и IdP, высокая производительность FLRS и GFLRS, параллельная обработка запросов, обеспечение малой задержки обмена данными между RADIUS-серверами.

Увеличение времени авторизации пользователей, по мнению авторов, является приемлемой платой за преимущества, которые предоставляет использование групп институтов и пользователей.

Литература

1.     Robinson A. Federated Identity Management in Higher Education, University of Baltimore, 2006.

2.     Rigney C., Simpson S., Willens A., Rubens W. RFC2865 – Remote Authentication Dial In User Service (RADIUS), IETF, 2010. URL: http://tools.ietf.org/html/rfc2865 (дата обращения: 19.09.2012).

3.     802.1X Port-Based Network Access Control, IEEE Computer Society. 2004. URL: http://standards.ieee.org/getieee802/ download/802.1X-2004.pdf (дата обращения: 19.09.2012).

4.     802.1Q Virtual Bridged Local Area Networks, IEEE Computer Society, 2005. URL: http://standards.ieee.org/getieee802/ download/802.1Q-2005.pdf (дата обращения: 19.09.2012).

5.     Aboba B., Blunk L., Vollbrecht J., Carlson J. RFC3748 – Extensible Authentication Protocol (EAP), IETF, 2004. URL: http://www.ietf.org/rfc/rfc3748.txt (дата обращения: 19.09.2012).

6.     RFC4511 – Lightweight Directory Access Protocol (LDAP): The Protocol, IETF. URL: http://tools.ietf.org/html/ rfc4511 (дата обращения: 19.09.2012).

7.     Zorn G., Leifer D., Rubens A., Shriver J., M. Holdrege M., Goyret I. RFC2868 – RADIUS Attributes for Tunnel Protocol Support, IETF, 2000. URL: http://tools.ietf.org/html/rfc2868 (дата обращения: 19.09.2012).


Permanent link:
http://swsys.ru/index.php?page=article&id=3302&lang=&lang=en&like=1
Print version
Full issue in PDF (9.63Mb)
Download the cover in PDF (1.26Мб)
The article was published in issue no. № 4, 2012 [ pp. 10-18 ]

Perhaps, you might be interested in the following articles of similar topics: