Diameter base protocol
Назва протоколи RADIUS - абревіатура від Remote Authentication Dial In User Service (General Packet віддаленої аутентифікації вхідних дзвінків користувачів). Назву називає область, де найчастіше застосовується RADIUS: аутентифікація входять підключень через користувачів до сервера віддаленого доступу.
Протокол розроблений в 1989 році фірмою Livingston (якраз і є великим виробником серверів віддаленого доступу), потім доработа в Мічиганському університеті, а потім прийнятий IETF і описаний в RFC 2138 і 2139. У такий чином RADIUS в даний момент - відкритий стандарт, що забезпечило йому популярність серед самих різних виробників обладнання.
RADIUS є клієнт-серверний протокол, який працює поверх UDP. Вибір UDP, а не TCP обумовлений тим, що в разі відмови сервера аутентифікації, UDP дозволяє швидше переключитися на запасний сервер. У той же час, використання UDP диктує необхідність реалізації схем контролю доставки та повторної передачі засобами самого протоколу RADIUS.
2. Формат пакета
Пакет RADIUS виглядає наступним чином:
Призначення полів пакету:
- Code - код запиту / відповіді (8 біт);
- Identifier - ідентифікатор (повинен збігатися у запиту і соотв. Відповіді; 8 біт);
- Length - довжина всього пакета (16 біт);
- Autheticator - поле перевірки автентичності відповіді сервера (16 байт);
- Attributes - дані запиту / відповіді.
Обмін між сервером і клієнтом (клієнтом RADIUS є сервер доступу, а не безпосередньо модемний користувач) поисходит за принципом запит-відповідь.
Можливі варіанти запитів і відповідей на них:
1. access-request: запит на доступ користувача до певних служб
- access-accept: позитивну відповідь, доступ дозволений.
- access-reject: негативну відповідь, доступ заборонений.
- access-challenge: запит додаткової інформації сервером, яку клієнт (сервер доступу) повинен надати в наступному запиті.
2. accounting request, запит розміщення даних обліку на сервері.
- accounting response, дані успішно розміщені на сервері.
3. Схема обміну інформацією
Нижче наведено приклад обміну інформацією між сервером доступу і сервером RADIUS при підключенні та відключенні користувача.
Протокол DIAMETER багато в чому нагадує RADIUS, однак має ряд переваг, які приведені в кінці цього розділу. DIAMETER розроблявся для застосування в одному середовищі з уже поширеним проотоколом RADIUS.
Базова версія, описана в документі draft-calhoun-diameter-10, забезпечує наступну функціональність:
- Надійну доставку повідомлень у виді UDP-дейтаграм
- Управління потоком ( "вікно" прийому)
- Своєчасне виявлення відмови серверів
- Доставку пар атрибут-значення (attribute-value pair, AVP)
- Можливість розширення за рахунок додавання нових видів AVP
2. Формат пакета
Сервер доступу і DIAMETER-сервер обмінюються повідомленнями по протоколу UDP.
Одному UDP-пакета відповідає одне повідомлення. Формат пакета подання платниками податку на нижче.
Опис полів пакету:
1. RADIUS PCC: Поле сумісність з RADIUS (Packet Compatibility Code, 1 байт). Містить значення 254, що позначає пакет DIAMETER.
2. Прапори (3 біта): в базовому протоколі призначення не визначено.
3. Прапор A (1 битий): повідомлення є квитанцією і не містить команд
4. Прапор W (1 біт): встановлюється, коли використовуються транспортні функції DIAMETER.
5. Version (Версія 3 біта): номер версії протоколу, нині 1.
6. Packet length (Довжина пакета, 2 байта): довжина всього пакета
7. Identifier (Ідентифікатор, 4 байта): значення, ісп. для зіставлення відповідей запитам.
8. NS (2 байта): поле, яке використовується при роботі в кач-ве транспортного протоколу.
9. NR (2 байта): поле, яке використовується при роботі в кач-ве транспортного протоколу.
- AVP Code (Код AVP, 4 байта): код команди
- AVP Length (Довжина AVP, 2 байта): довжина цієї AVP
- Прапори (6 біт): використовуються в залежності від команди
- Резерв (6 біт)
- Прапор T (1 біт): прапор присутності поля Tag, використовуваного для об'єднання AVP.
- Прапор V (1 біт): позначає наявність необов'язкового поля Vendor ID.
- Прапор H (1 біт): прапор використання шифрування AVP.
- Прапор M (1 біт): прапор обов'язковості підтримки даної AVP.
- Vendor ID (4 байта, необов'язкове): ідентифікатор виробника.
- Tag (4 байта, необов'язкове).
3. Схема обміну інформацією
Нижче наведена схема обміну інформацією при реєстрації і подальшому виході користувача з системи. Повідомлення, зображені на схемі, пересилаються з використанням UDP, поверх якого працює власна реалізація механізму віконного керування потоком. На кожен отриманий пакет приймаючою стороною надсилається підтвердження (на схемі не відображено).
Як видно, протоколи RADIUS і DIAMETER схожі в принципі роботи і навіть в форматі пакетів. Однак є і суттєві відмінності.
Алгоритм повторної передачі.
В пакетах RADIUS під ідентифікатор відводиться 1 байт, що обмежує число запитів, які очікують підтвердження (255). У DIAMETER на ID відводяться 4 байту.
Засоби управління потоком.
RADIUS не передбачає ніяких засобів управління потоком повідомлень між клієнтом і сервером, в той час як DIAMETER використовує ефективну віконну схему управління потоком.
підтвердження
RADIUS передбачає підтвердження повідомлень, але в разі роботи проксі встановити, чи отримав сервер повідомлення не представляється можливим.
DIAMETER вимагає від сервера підтвердження отримання повідомлення і вто же час дозволяє працювати проксі.
Повідомлення про помилки
Для беруть участь в RADIUS-обміні сторін не передбачена відсилання повідомлень про помилки, що може дозволити однієї зі сторін вважати, що команда була виконана, в той час як насправді в повідомленні була виявлена помилка і він був відкинутий.
DIAMETER дає можливість боці повідомити іншу про помилку.
Повідомлення про припинення роботи
Хоча RADIUS і дозволяє виявити вихід сервер з ладу, проте DIAMETER дає можливість повідомити клієнтів про припинення роботи сервера і таким чином здійснити перехід на запасний сервер без затримок.
Захист даних від сервера до клієнта
RADIUS передбачає захист даних лише між безпосередньо обмінюються вузлами. Будь проміжний вузол (проксі) може змінити дані і така зміна не може бути виявлено. DIAMETER ж не дозволяє проксі міняти інформацію.
Підтримка додаткових команд
RADIUS не підтримує додаткових до певних в протоколі команд.
DIAMETER спочатку проектувався з урахуванням можливості розширення (передбачена можливість додавання нових AVP).
складність обробки
RADIUS не визначає вимог щодо вирівнювання цих.
DIAMETER вимагає вирівнювання по 32-бітній границі, що полегшує обробку на більшості процессоров.
TACACS (Terminal Access Controller Access Control System) - протокол, який використовували ще в старогліняние часи на серверах доступу ще аж ARPANET. Проте, ідея все та ж сама: центральний сервер, який приймає рішення, дозволити або не дозволити певного користувачеві підключитися до мережі. TACACS не передбачає збору будь-якої статистики. Таким чином від AAA залишається AA.
TACACS описаний в документі RFC тисяча чотиреста дев'яносто дві.
Існують 2 версії TACACS: вихідна, що використовувалась в ARPANET і новіша, допрацьована і пременявшаяся (до появи TACACS +) Cisco.
2. Формат пакета
Перш за все, зробимо необходімлое уточнення: тут описується оригінальний варіант TACACS без розширень Cisco (т.зв. simple form of packet, проста форма).
Деякі зауваження по розширень, зробленим Cisco, будуть дані в кінці розділу.
Повідомлення TACACS пересилаються в детаграммах UDP - строго по одному в кожній.
Клієнт (сервер доступу) відправляє серверу запити в наступному форматі:
"Version (Версія, 1 байт): проста форма (0)
"Type (Тип запиту, 1 байт): в простій формі - тільки LOGIN, SUPERUSER і LOGOUT
"Nonce (Номер, 2 байта): довільне число, Поволяев зіставити запит і відповідь.
"Username length (Довжина імені користувача, 1 байт)
"Password length (Довжина пароля, 1 байт)
"Data (Дані, довжина змінна): ім'я користувача і пароль.
Сервер відповідає повідомленням наступного формату:
Призначення полів ті ж, за винятком:
- Response (Відповідь, 1 байт): код відповіді - пароль прийнятий або відкинутий.
- Reason (Причина, 1 байт): додаткова інформація за Response = rejected.
- Поле даних відсутня.
3. Схема обміну TACACS
Робота TACACS гранично проста:
1. Клієнт (сервер доступу) надсилає запит LOGIN з ім'ям і паролем, отриманими від користувача.
2. Сервер TACACS відповідає або кодом accepted (і тоді Reason = 0), або rejected і тоді Reason містить додатковий код: expiring, password або denied.
2.1. Під час Сенсу зв'язку (після успішного LOGIN) користувач може зажадати додаткові привілеї (SUPERUSER). Інтерпретація цього поняття залежить від реалізації.
3. Після закінчення сеансу сервер доступу відправляє повідомлення LOGOUT (і встановлює Reason = quit, idle, drop або bad)
4. Сервер TACACS підтверджує отримання LOGOUT успешшним кодом завершення.
4. Розширення Cisco
Cisco розширила функціональність TACACS для своїх потреб. Була введена т.зв. розширена форма запиту (Version = 128): додані декілька нових полів, додана підтримка SLIP, а також робота по протоколу TCP з іншим форматом запитів і відповідей (текстовим, схожим на FTP і SMTP).
Описувати ці розширення особливого сенсу немає, тому що сама Cisco вже давно використовує TACACS +.
2. Формат пакетів
Оскільки TACACS + є сеансовим протоколом, то і працює він поверх TCP.
Для всіх передачі всіх типів повідомлень в обох напрямках використовується один формат TACACS + пакета.
Поле Type визначає тип сеансу, якому належить даний пакет: Authentication, Authorization або Accounting.
Session ID дозволяє встановлювати в рамках одного TCP-з'єднання кілька сесій.
Як вже було сказано, TACACS + складається з трьох частин, які можуть працювати незалежно один від одного. Наведемо їх роботу.
3 .1. Процес аутентифікації (утановленіе сеансу authentication).
Для сеансу authentication визначені три типи пакетів: START, CONTINUE і REPLY.
Клієнт направляє серверу пакети START і CONTINUE, сервер відповідає REPLY.
Сеанс починається з посилки клієнтом пакету START, що містить:
- Використовуваний метод аутентифікації: ASCII, PAP, CHAP, ARAP, MSCHAP.
- Рівень доступу, для которог буде виконуватися аутентифікація. Зумовлені 4 рівня доступу: MIN, USER, ROOT і MAX.
- Дані (або частина, або нічого - в залежності від методу та бажання клієнта) для аутентифікації.
У відповідь на START сервер повинен послати REPLY, з одним з можливих результатів (залежних від методу автентифікації):
- PASS - повідомлення про успішне проходження аутентифікації.
- FAIL - про недачной спробі.
- GETUSER - запит імені користувача. Наприклад, якщо був обраний метод ASCII, але ім'я користувача не було включено в пакет START.
- GETPASS - запит пароля.
- GETDATA - запит додаткових відомостей. Використовується в інших методах.
Різні методи аутентифікації можуть зажадати обміну різною кількістю повідомлень між клієнтом (сервером доступу) і сервером TACACS +.
Усі наступні (після START) пакети від клієнта повинні бути CONTINUE.
Клієнт може перервати сеанс в будь-який час, встановивши прапор ABORT в черговому пакеті CONTINUE.
Сервер може запросити переустановку сеансу (статус RESTART в пакеті REPLY), а також перенаправити клієнта (статус FOLLOW в пакеті REPLY). В цьому випадку сервер в поле даних пакета передає список серверів.
- Клієнт пакетом REQUEST запитує права на використання опрелённих служб.
- Сервер відповідає пакетом RESPONSE, що містить код відповіді.
Клієнт направляє серверу REQUEST, в якому визначає набір параметрів обліку.
Information is borrowed from: