тупу клієнту RADIUS повідомляється, що спроба з'єднання була успішно аутентифицироваться і авторизуємо;
· Access-Reject - «доступ не дозволено». Ця відповідь сервера RADIUS означає, що спроба доступу до мережі не вдалася. Таке можливо в тому випадку, якщо для користувача даних недостатньо для успішної аутентифікації або доступ для користувача не авторизований;
· Access-Challenge - «виклик запиту». Сервер RADIUS передає його у відповідь на запит доступу;
· Accounting-Request - «запит обліку», який клієнт RADIUS відсилає для введення облікової інформації після отримання дозволу на доступ;
· Accounting-Response - «відповідь обліку». Таким чином сервер RADIUS реагує на запит обліку та підтверджує факт обробки запиту обліку.
Повідомлення RADIUS завжди складається із заголовка і атрибутів, кожен з яких містить ту чи іншу інформацію про спробу доступу: наприклад, ім'я та пароль користувача, запитувані послуги і IP-адресу сервера доступу. Таким чином, головним завданням атрибутів RADIUS є транспортування інформації між клієнтами, серверами та іншими агентами RADIUS. Атрибути RADIUS визначені в декількох RFC: RFC +2865, RFC 2866, RFC +2867, RFC 2868, RFC +2869 і RFC +3162.
Для захисту повідомлень клієнт і сервер RADIUS володіють «загальним секретом» або, простіше кажучи, ключем. При цьому мова, як правило, йде про ланцюжку символів, наявної як на серверах, так і на клієнті RADIUS.
Протоколи аутентифікації:
У налаштуваннях клієнтського ПЗ бездротової мережі можна виявити абревіатури EAP, EAP-TLS, PEAP-MSCHAP-V2 та інші. Вони позначають різні протоколи аутентифікації. Так, EAP (Extensible Authentication Protocol, Розширюваний протокол аутентифікації) являє собою контейнер для протоколів, які фактично здійснюють передачу запитів аутентифікацію і відповідей аутентифікатора. Оскільки EAP абстрагований від конкретних процедур аутентифікації, мережеве обладнання, що підтримує EAP, теж не пов'язано з будь-якими конкретними протоколами.
Компанія Microsoft розробила на основі EAP протокол EAP-TLS, прийнятий пізніше в якості стандарту. Протокол EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) реалізує двосторонню аутентифікацію з використанням сертифікатів X.509 обома сторонами. PEAP (Protected Extensible Authentication Protocol) являє собою розширення протоколу EAP. На відміну від EAP, протокол PEAP створює безпечний тунель перед початком процесу аутентифікації. Далі з цього тунелю передаються дані для аутентифікації. Наявність безпечного тунелю ускладнює перехоплення даних зловмисником. Як і EAP, PEAP являє собою контейнер для високорівневих протоколів аутентифікації, в яких аутентифікація виконується за допомогою імені облікового запису та пароля. Ще один протокол, EAP-TTLS, також використовує безпечні тунелі для передачі даних. Як і в EAP-TLS, в EAP-TTLS реалізована двостороння аутентифікація (сервер засвідчує себе за допомогою сертифіката X.509).
Розширений протокол аутентифікації (EAP):
Розширений протокол аутентифікації (Extensible Authentication Protocol, EAP) спочатку замислювався як додаток до РРР для підтримки різних механізмів аутентифікації доступу до мережі. Протоколи аутентифікації для РРР, визначають механізм аутентифікації під час фази встановлення з'єднання. На цьому етапі необхідно застосовувати узгоджений протокол аутентифікації, з метою «верифікації» з'єднання. У даному випадку мова йде про заздалегідь певній послідовності повідомлень, причому вони повинні надсилатися відповідно до заданої схемою, а точніше, у зазначеній черговості.
При використанні EAP в процесі встановлення з'єднання в рамках РРР спеціальний механізм аутентифікації не визначається. Лише на етапі аутентифікації учасники взаємодіють за спеціальною схемою аутентифікації EAP, обозначаемой також як «схема типу EAP».
ЕАР дозволяє здійснювати обмін повідомленнями між клієнтом, запитувачам доступ, і аутентифицирующей сервером (в його ролі часто виступає сервер RADIUS). При цьому обмін повідомленнями може варіюватися з урахуванням особливостей різних сполук; він складається власне із запитів, в яких вимагається надання інформації про аутентифікації, а також з відповідних відповідей. Тривалість і конкретні деталі сеансу аутентифікації залежать від заданої схеми EAP.
В архітектурному плані ЕАР замислювався таким чином, щоб аутентифікацію можна було виконувати за допомогою підключених модулів з обох сторін з'єднання: від клієнта і від сервера. Якщо бібліотечний файл ЕАР встановити на обох кінцях, то в будь-який момент можна застосувати нову схему аутентифікації. Тим самим ЕАР надає гнучку середовище для впровадження безпечних методів ауте...
