Наз­ва­ние RA­DI­US яв­ля­ет­ся абб­ре­ви­ату­рой от Re­mote Aut­henti­cati­on Di­al In User Ser­vi­ce и предс­тав­ля­ет со­бой се­тевой про­токол, обес­пе­чива­ющий цент­ра­лизо­ван­ную Аутен­ти­фика­цию (Aut­henti­cati­on), Ав­то­риза­цию (Aut­ho­riza­ti­on) и Учет ис­поль­зу­емых се­тевых ре­сур­сов (Ac­co­un­ting). В анг­ло­языч­ной ли­тера­туре для этих трех функ­ций (Aut­henti­cati­on, Aut­ho­riza­ti­on, Ac­co­un­ting) ис­поль­зу­ет­ся абб­ре­ви­ату­ра ААА.

Под Аутен­ти­фика­ци­ей по­нима­ет­ся про­цесс, поз­во­ля­ющий иден­ти­фици­ровать поль­зо­вате­ля по его дан­ным, нап­ри­мер, по ло­гину (имя поль­зо­вате­ля, но­мер те­лефо­на и т. д.) и па­ролю.

Ав­то­риза­ция - про­цесс, в те­чение ко­торо­го оп­ре­деля­ют­ся пол­но­мочия иден­ти­фици­рован­но­го поль­зо­вате­ля на дос­туп к оп­ре­делён­ным се­тевым ре­сур­сам.

Тер­мин Учет ис­поль­зо­ван­ных се­тевых ре­сур­сов уже сам по се­бе дос­та­точ­но ин­форма­тивен. Пер­вичны­ми дан­ны­ми, ко­торые пе­реда­ют­ся по про­токо­лу RA­DI­US, яв­ля­ют­ся объемы вхо­дяще­го и ис­хо­дяще­го тра­фиков при пе­реда­че дан­ных, и дли­тель­ность раз­го­вора и наб­ранный но­мер при ис­поль­зо­вании IP те­лефо­нии. Кро­ме оп­ре­делен­ных в про­токо­ле стан­дарт­ных ат­ри­бутов (па­рамет­ров), про­токол пре­дус­матри­ва­ет воз­можность ис­поль­зо­вания про­из­во­дите­лем обо­рудо­вания (вен­до­ром) собс­твен­ных ат­ри­бутов. В анг­ло­языч­ной ли­тера­туре они на­зыва­ют­ся Ven­dor Spe­cific Att­ri­butes или VSA.

Про­токол RA­DI­US был раз­ра­ботан ком­па­ни­ей Li­ving­ston En­terp­ri­ses (конк­рет­но Кар­лом Риг­ней/Carl Rig­ney) для уда­лен­но­го ком­му­тиру­емо­го дос­ту­па че­рез се­тевые сер­ве­ра дос­ту­па (Net­work Ac­cess Ser­ver - NAS) этой ком­па­нии се­рии Port­Mas­ter к се­ти in­ternet. Поз­же, в 1997, про­токол RA­DI­US был опуб­ли­кован как RFC 2058 иRFC 2059. Те­кущие вер­сии RFC 2865 (Re­mote Aut­henti­cati­on Di­al In User Ser­vi­ce (RA­DI­US)) и RFC 2866 (RA­DI­US Ac­co­un­ting). Иног­да вмес­то по­нятия "се­тевой сер­вер дос­ту­па" ис­поль­зу­ет­ся дру­гой: "уда­лен­ный сер­вер дос­ту­па" (Re­mote Ac­cess Ser­ver – RAS).

В нас­то­ящее вре­мя про­токол RA­DI­US ис­поль­зу­ет­ся для дос­ту­па к вир­ту­аль­ным част­ным се­тям (VPN), точ­кам бесп­ро­вод­но­го (Wi-Fi) дос­ту­па, Et­hernet ком­му­тато­рам, DSL и дру­гим ти­пам се­тево­го дос­ту­па. Бла­года­ря отк­ры­тос­ти, прос­то­те внед­ре­ния, пос­то­ян­но­му усо­вер­шенс­тво­ванию, про­токол RA­DI­US сей­час яв­ля­ет­ся фак­ти­чес­ки стан­дартом для уда­лен­ной аутен­ти­фика­ции.

Аутен­ти­фика­ция и ав­то­риза­ция

Для вы­яс­не­ния ра­боты RA­DI­US про­токо­ла расс­мот­рим ри­сунок, при­веден­ный ни­же.


 Но­ут­бу­ки и IP те­лефон, предс­тав­ля­ют уст­рой­ства поль­зо­вате­ля, с ко­торых не­об­хо­димо вы­пол­нить аутен­ти­фика­ции и ав­то­риза­ции на се­тевых сер­ве­рах дос­ту­па (NAS):

  • точ­ке Wi-Fi дос­ту­па,
  • марш­ру­тиза­торе,
  • VPN сер­ве­ре и
  • IP АТС.

На ри­сун­ке по­каза­ны не все воз­можные ва­ри­ан­ты NAS. Су­щест­ву­ют и дру­гие се­тевые уст­рой­ства дос­ту­па.

RA­DI­US про­токол ре­али­зовы­ва­ет­ся в ви­де ин­терфей­са меж­ду NAS, ко­торый выс­ту­па­ет как RA­DI­US кли­ент, и RA­DI­US сер­ве­ром – прог­рамм­ным обес­пе­чени­ем, ко­торое мо­жет быть ус­та­нов­ле­но на компьюте­ре (сер­ве­ре) или ка­ком-то спе­ци­али­зиро­ван­ном уст­рой­стве. Та­ким об­ра­зом, RA­DI­US сер­вер, как пра­вило, не вза­имо­дей­ству­ет нап­ря­мую с уст­рой­ством поль­зо­вате­ля, а толь­ко че­рез се­тевой сер­вер дос­ту­па.

Поль­зо­ватель по­сыла­ет зап­рос на се­тевой сер­вер дос­ту­па для по­луче­ния дос­ту­па к оп­ре­делен­но­му се­тево­му ре­сур­су, ис­поль­зуя сер­ти­фикат дос­ту­па. Сер­ти­фикат по­сыла­ет­ся на се­тевой сер­вер дос­ту­па че­рез се­тевой про­токол ка­наль­но­го уров­ня (Link La­yer), нап­ри­мер, Po­int-to-Po­int Pro­tocol (PPP) в слу­чае вы­пол­не­ния ком­му­тиру­емо­го дос­ту­па, Di­gital Subs­cri­ber Li­ne (DLS) – в слу­чае ис­поль­зо­вания со­от­ветс­тву­ющих мо­демов и т.п. NAS пос­ле это­го, в свою оче­редь, по­сыла­ет со­об­ще­ние зап­ро­са дос­ту­па на RA­DI­US сер­вер, так на­зыва­емый RA­DI­US Ac­cess Re­qu­est. Этот зап­рос вклю­ча­ет сер­ти­фика­ты дос­ту­па, ко­торые обыч­но предс­тав­ле­ны в ви­де име­ни поль­зо­вате­ля и па­роля или сер­ти­фика­та бе­зопас­ности, по­лучен­ных от поль­зо­вате­ля. Кро­ме это­го зап­рос мо­жет со­дер­жать до­пол­ни­тель­ные па­рамет­ры, та­кие как се­тевой ад­рес уст­рой­ства поль­зо­вате­ля, его те­лефон­ный но­мер, ин­форма­цию о фи­зичес­ком ад­ре­се, с ко­торо­го поль­зо­ватель вза­имо­дей­ству­ет с NAS.

RA­DI­US сер­вер про­веря­ет эту ин­форма­цию на кор­рект­ность, ис­поль­зуя та­кие схе­мы аутен­ти­фика­ции, как PAP, CHAP, EAP и т.п. 
Крат­ко опи­шем эти про­токо­лы.
PAP (Pass­word Aut­henti­cati­on Pro­tocol) (RFC1334)– прос­той аутен­ти­фика­ци­он­ный про­токол, ко­торый ис­поль­зу­ет­ся для аутен­ти­фика­ции поль­зо­вате­ля по от­но­шению к се­тево­му сер­ве­ру дос­ту­па (NAS). РАР ис­поль­зу­ет­ся РРР про­токо­лом. Прак­ти­чес­ки все сер­ве­ра дос­ту­па под­держи­ва­ют РАР. РАР пе­реда­ет не­зашиф­ро­ван­ный па­роль че­рез сеть и, сле­дова­тель­но, яв­ля­ет­ся не­защи­щен­ным про­токо­лом. По­это­му РАР, обыч­но, ис­поль­зу­ет­ся в том слу­чае, ког­да сер­вер не под­держи­ва­ет за­щищен­ные про­токо­лы, та­кие как СНАР, ЕАР и т.п.

CHAP (англ. Chal­lenge Hand­sha­ke Aut­henti­cati­on Pro­tocol) (RFC 1994) — ши­роко расп­рос­тра­нён­ный ал­го­ритм про­вер­ки под­линнос­ти, пре­дус­матри­ва­ющий пе­реда­чу не са­мого па­роля поль­зо­вате­ля, а кос­венных све­дений о нём. При ис­поль­зо­вании CHAP сер­вер уда­лен­но­го дос­ту­па отп­рав­ля­ет кли­ен­ту стро­ку зап­ро­са. На ос­но­ве этой стро­ки и па­роля поль­зо­вате­ля кли­ент вы­чис­ля­ет хеш-код MD5 (Mes­sa­ge Di­gest-5) и пе­реда­ет его сер­ве­ру. Хеш-функ­ция яв­ля­ет­ся ал­го­рит­мом од­носто­рон­не­го (не­об­ра­тимо­го) шиф­ро­вания, пос­коль­ку зна­чение хеш-функ­ции для бло­ка дан­ных вы­чис­лить лег­ко, а оп­ре­делить ис­ходный блок по хеш-ко­ду с ма­тема­тичес­кой точ­ки зре­ния не­воз­можно за при­ем­ле­мое вре­мя. (По хе­широ­ванию су­щест­ву­ет мно­го ли­тера­туры, нап­ри­мер, мож­но про­честь: Хе­широ­вание). Сер­вер, ко­торо­му дос­ту­пен па­роль поль­зо­вате­ля, вы­пол­ня­ет те же са­мые вы­чис­ле­ния и срав­ни­ва­ет ре­зуль­тат с хеш-ко­дом, по­лучен­ным от кли­ен­та. В слу­чае сов­па­дения учёт­ные дан­ные кли­ен­та уда­лён­но­го дос­ту­па счи­та­ют­ся под­линны­ми.
MD5 (Mes­sa­ge-Di­gest al­go­rithm 5) (RFC 1321) — ши­роко ис­поль­зу­емая крип­тогра­фичес­кая функ­ция с 128 би­товым хе­шем. Най­ден ряд уяз­ви­мос­тей в ал­го­рит­ме MD5, в си­лу че­го в США де­пар­та­мент U. S. De­part­ment of Ho­meland Se­curi­ty не ре­комен­ду­ет ис­поль­зо­вание MD5 в бу­дущем, и для боль­шинс­тва пра­витель­ствен­ных при­ложе­ний c 2010 го­да США тре­бу­ет­ся пе­рей­ти на се­мей­ство ал­го­рит­ма SHA-2.

Про­токол EAP (Ex­tensib­le Aut­henti­cati­on Pro­tocol) (RFC 3748) поз­во­ля­ет про­верять под­линность при подк­лю­чени­ях уда­лен­но­го дос­ту­па с по­мощью раз­личных ме­ханиз­мов про­вер­ки под­линнос­ти. Точ­ная схе­ма про­вер­ки под­линнос­ти сог­ла­совы­ва­ет­ся кли­ен­том уда­лен­но­го дос­ту­па и сер­ве­ром, вы­пол­ня­ющим про­вер­ку под­линнос­ти (им мо­жет быть сер­вер уда­лен­но­го дос­ту­па или RA­DI­US сер­вер). По умол­ча­нию в марш­ру­тиза­цию и уда­лен­ный дос­туп вклю­чена под­держ­ка про­токо­лов EAP-TLS и MD5-Chal­lenge (MD5-за­дача). Подк­лю­чение дру­гих мо­дулей ЕАР к сер­ве­ру, ис­поль­зу­юще­му марш­ру­тиза­цию и уда­лен­ный дос­туп, обес­пе­чива­ет под­держ­ку дру­гих ме­тодов ЕАР.
Про­токол EAP поз­во­ля­ет вес­ти сво­бод­ный ди­алог меж­ду кли­ен­том уда­лен­но­го дос­ту­па и сис­те­мой про­вер­ки под­линнос­ти. Та­кой ди­алог сос­то­ит из зап­ро­сов сис­те­мы про­вер­ки под­линнос­ти на не­об­хо­димую ей ин­форма­цию и от­ве­тов кли­ен­та уда­лен­но­го дос­ту­па. Нап­ри­мер, ког­да про­токол EAP ис­поль­зу­ет­ся с ге­нера­тора­ми ко­дов дос­ту­па, сер­вер, вы­пол­ня­ющий про­вер­ку под­линнос­ти, мо­жет от­дель­но зап­ра­шивать у кли­ен­та уда­лен­но­го дос­ту­па имя поль­зо­вате­ля, иден­ти­фика­тор и код дос­ту­па. Пос­ле от­ве­та на каж­дый та­кой зап­рос кли­ент уда­лен­но­го дос­ту­па про­ходит оп­ре­делен­ный уро­вень про­вер­ки под­линнос­ти. Ког­да на все зап­ро­сы бу­дут по­луче­ны удов­летво­ритель­ные от­ве­ты, про­вер­ка под­линнос­ти кли­ен­та уда­лен­но­го дос­ту­па ус­пешно за­вер­ша­ет­ся.
Схе­мы про­вер­ки под­линнос­ти, ис­поль­зу­ющие про­токол EAP, на­зыва­ют­ся ти­пами EAP. Для ус­пешной про­вер­ки под­линнос­ти кли­ент уда­лен­но­го дос­ту­па и сер­вер, вы­пол­ня­ющий про­вер­ку под­линнос­ти, долж­ны под­держи­вать один и тот же тип EAP.

Те­перь вер­немся к RA­DI­US сер­ве­ру, ко­торый про­веря­ет ин­форма­цию, по­лучен­ную от NAS. Сер­вер про­веря­ет иден­тичность поль­зо­вате­ля, а так­же кор­рект­ность до­пол­ни­тель­ной ин­форма­ции, ко­торая мо­жет со­дер­жать­ся в зап­ро­се: се­тевой ад­рес уст­рой­ства поль­зо­вате­ля, те­лефон­ный но­мер, сос­то­яние сче­та, его при­виле­гии при дос­ту­пе к зап­ра­шива­емо­му се­тево­му ре­сур­су.
По ре­зуль­та­там про­вер­ки RA­DI­US сер­вер по­сыла­ет NAS один из трех ти­пов отк­ли­ков:

  • Ac­cess-Re­ject по­казы­ва­ет, что дан­ный поль­зо­ватель­ский зап­рос не­вер­ный. При же­лании сер­вер мо­жет вклю­чить текс­то­вое со­об­ще­ние в Ac­cess-Re­ject, ко­торое мо­жет быть пе­реда­но кли­ен­том поль­зо­вате­лю. Ни­какие дру­гие ат­ри­буты (кро­ме Pro­xy-Sta­te) не раз­ре­шены в Ac­cess-Re­ject.
  • Ac­cess-Chal­lenge. Зап­рос до­пол­ни­тель­ной ин­форма­ции от поль­зо­вате­ля, нап­ри­мер, вто­рой па­роль, пин-код, но­мер кар­ты и т.п. Этот отк­лик так­же ис­поль­зу­ет­ся для бо­лее пол­но­го аутен­ти­фика­ци­он­но­го ди­ало­га, где за­щит­ный тун­нель вы­пол­ня­ет­ся меж­ду уст­рой­ством поль­зо­вате­ля и RA­DI­US сер­ве­ром, так что сер­ти­фика­ты дос­ту­па скры­ва­ют­ся от NAS.
  • Ac­cess Ac­cept. Поль­зо­вате­лю раз­ре­шен дос­туп. Пос­коль­ку поль­зо­ватель аутен­ти­фици­рован, то RA­DI­US сер­вер про­веря­ет ав­то­риза­цию на ис­поль­зо­вание зап­ро­шен­ных поль­зо­вате­лем ре­сур­сов. Нап­ри­мер, поль­зо­вате­лю мо­жет быть дос­туп че­рез бесп­ро­вод­ную сеть, но зап­ре­щен дос­туп к VPN се­ти.


Та­ким об­ра­зом, ра­бота RA­DI­US про­токо­ла мо­жет в об­щем слу­чае быть предс­тав­ле­на, как по­каза­но на таб­ли­це ни­же.

Сер­вер дос­ту­па
Нап­равле­ние
RA­DI­US сер­вер
Ac­cess-Re­qu­est: NAS-Iden­ti­fi­er, NAS-Port, User-Na­me, User-Pass­word (па­роль мо­жет быть про­иг­но­риро­ван)
 
 
Ac­cess-Chal­lenge: Sta­te (0 или 1) и Rep­ly-Mes­sa­ge (Нап­ри­мер: "Chal­lenge 12345678, en­ter your res­ponse at the prompt")
Ac­cess-Re­qu­est: с но­вым ID, NAS-Iden­ti­fi­er, NAS-Port, User-Na­me, User-Pass­word (па­роль крип­тогра­фиру­ет­ся). Sta­te (тот же, что и в Ac­cess-Chal­lenge)
 
 
Ac­cess-Chal­lenge: Sta­te (0 или 1) и Rep­ly-Mes­sa­ge (Нап­ри­мер: "Chal­lenge 12345678, en­ter your res­ponse at the prompt")



Учет ис­поль­зо­ван­ных се­тевых ре­сур­сов

Пос­ле то­го, как NAS раз­ре­шил поль­зо­вате­лю дос­туп, NAS по­сыла­ет RA­DI­US сер­ве­ру со­об­ще­ние о на­чале уче­та се­тево­го дос­ту­па – па­кет Ac­co­un­ting Re­qu­est, ко­торый со­дер­жит ат­ри­бут Acct-Sta­tus-Ty­pe со зна­чени­ем "start". Это со­об­ще­ние обыч­но со­дер­жит иден­ти­фика­тор поль­зо­вате­ля, его се­тевой ад­рес, порт подк­лю­чения и уни­каль­ный иден­ти­фика­тор сес­сии.

NAS мо­жет пе­ри­оди­чес­ки по­сылать RA­DI­US сер­ве­ру па­кет Ac­co­un­ting Re­qu­est, со­дер­жа­щий ат­ри­бут Acct-Sta­tus-Ty­pe со зна­чени­ем "in­te­rim-up­da­te". По­доб­ная ин­форма­ция пред­назна­чена для об­новле­ния ста­туса поль­зо­вате­ля во вре­мя ак­тивной сес­сии. Обыч­но по­доб­ная ин­форма­ция соп­ро­вож­да­ет­ся ин­форма­ци­ей о те­кущей да­те и про­дол­жи­тель­нос­ти сес­сии.

Пос­ле прек­ра­щения поль­зо­вате­лем дос­ту­па к се­ти NAS по­сыла­ет RA­DI­US сер­ве­ру пос­ледний па­кет Ac­co­un­ting Re­qu­est, ко­торый со­дер­жит ат­ри­бут Acct-Sta­tus-Ty­peсо зна­чени­ем "stop". Так­же пе­реда­ет­ся ин­форма­ция о вре­мени сес­сии, ко­личест­ве пе­редан­ных па­кетов, ко­личест­ве пе­редан­ных бай­тов, при­чине окон­ча­ния со­еди­нения и дру­гая ин­форма­ция, свя­зан­ная с се­тевым дос­ту­пом.

Обыч­но, RA­DI­US кли­ент по­сыла­ет па­кет Ac­co­un­ting Re­qu­est с воз­можным пов­то­ром че­рез не­кото­рый ин­тервал вре­мени, по­ка не по­лучит в от­вет от RA­DI­US сер­ве­ра подт­вер­жде­ние при­ема – па­кет Ac­co­un­ting-Res­ponse.

Ос­новная цель этих дан­ных – ис­поль­зо­вание их для выс­тавле­ния сче­тов, од­на­ко, они мо­гут ис­поль­зо­вать­ся так­же для по­луче­ния ста­тис­ти­ки по пре­дос­тавля­емым ус­лу­гам и для об­ще­го се­тево­го мо­нито­рин­га.

Обыч­но, для аутен­ти­фика­ции и ав­то­риза­ции RA­DI­US сер­ве­ром ис­поль­зу­ет­ся 1812 UDP порт, а для уче­та ус­луг - 1813 UDP порт. Од­на­ко, в ря­де слу­ча­ев мо­гут ис­поль­зо­вать­ся и дру­гие пор­ты. В част­нос­ти, уст­рой­ства Cis­co Sys­tems по умол­ча­нию ис­поль­зу­ют 1645 и 1646 пор­ты со­от­ветс­твен­но.

В нас­то­ящее вре­мя су­щест­ву­ет це­лый ряд ре­али­заций RA­DI­US сер­ве­ров раз­личны­ми фир­ма­ми. Мы ре­комен­ду­ем ис­поль­зо­вать Soft­PI RA­DI­US сер­вер.