RADIUS ( Remote Authentication Dial-In User Service ) er en klient-server- protokoll som brukes til å sentralisere autentiseringsdata . RADIUS-protokollen ble oppfunnet og utviklet i 1991 av Livingston enterprise (ervervet av Lucent Technologies), som produserte nettverksadgangsservere for maskinvare bare utstyrt med serielle grensesnitt; den ble senere standardisert av IETF.
Den siste versjonen av RADIUS-protokollen er standardisert av IETF i to RFCer : RFC 2865 (RADIUS-autentisering) og RFC 2866 (RADIUS-regnskap) avJuni 2000. Etterfølgeren til RADIUS-protokollen kan være Diameter- protokollen (ordspill på dobbelt radius). Protokollen kalles ofte AAA ( Authentication Authorization Accounting ), autorisasjonsfasen (definisjon av tilgangsrettigheter) utføres under identifikasjonsresponsen (tillegg av attributter til "Authentication Response" -pakken ). Et annet eksempel på AAA-protokoll kan være TACACS fra Cisco , men den eier; og siden publiseringen av 802.1X-standarden som gir i vedlegg D som det eneste eksemplet på implementering av Radius-protokollen, har sistnevnte blitt en de facto-standard for AAA.
Det opprinnelige formålet med RADIUS var å tillate Internett-leverandører å autentisere eksterne brukere ved hjelp av PSTN- modemforbindelser fra flere servere, men en enkelt brukerbase. I den forrige situasjonen måtte brukernavn og passord dupliseres i hver enhet som trengte å identifisere brukere. På samme måte måtte POP- godkjenning (elektronisk post) håndteres på denne måten. Identifikasjonen på nettsteder med et navn og et passord administreres også i RADIUS, Apache-serveren er en av de mest utbredte Radius-klientene. Dette er fortsatt den vanligste bruken av RADIUS-protokollen: Internett-tilkoblingsnavn og passord, men flere og flere trådløse og kablede nettverk bruker den også til å identifisere brukere.
RADIUS-protokollen gjør det mulig å opprette forbindelsen mellom identifikasjons behov og en bruker basen ved å sørge for transport av autentiseringsdata på en standardisert måte. Den autentiseringsoperasjon blir initiert av en RADIUS-tjeneste klient , som kan være en ekstern tilgang boks (NAS: Network Access Server), et trådløst nettverksaksesspunkt, en brannmur, en bryter, en annen server. Serveren behandler det ved å få tilgang til en ekstern database om nødvendig: SQL- database , LDAP- katalog , maskin- eller domenebrukerkontoer; en Radius-server har et visst antall grensesnitt eller metoder for dette.
Brukerstasjonen ( supplikant i RFC-ene) overfører en tilgangsforespørsel til en RADIUS-klient for å komme inn i nettverket. Denne klienten er ansvarlig for å be om informasjonen som identifiserer brukeren: for eksempel brukernavnet (innlogging) og passord .
RADIUS-klienten genererer i henhold til protokollen en tilgangsforespørsel som inneholder autentiseringsinformasjonen . RADIUS-serveren kan behandle denne forespørselen selv eller overføre den til en annen RADIUS-server ved hjelp av en mekanisme som kalles Proxy Radius. Radius-serveren som er ansvarlig for den endelige identifikasjonen (kalt Home Radius) kan behandle forespørselen hvis den har tilstrekkelige elementer i Access-Request eller be om ytterligere informasjon ved å sende en "Access Challenge" -pakke, som klienten vil svare på med en annen "Access". -Request ", og så videre. Børsene overføres på nytt av kjeden av mellomliggende proxy-servere Radius i den ene retningen og den andre.
Når Radius-serveren har nok elementer (opptil et dusin sentraler for komplekse EAP- type protokoller ) validerer eller nekter RADIUS-serveren identifikasjonen ved å returnere en pakke av typen: Access-Accept eller Access-Reject .
RADIUS kjenner innfødt to passordprotokoller: PAP (klar utveksling av navn og passord) og CHAP (utveksling basert på en hash på begge sider med kun utveksling av " utfordringen "). Protokollen gir to separate attributter: Brukerpassord og CHAP-passord.
Siden den gang har Microsoft-variasjoner blitt lagt til: MS-CHAP og MS-CHAP-V2; deres likhet med CHAP gjør at de kan transporteres i RADIUS på samme måte, på initiativ fra serveren og underlagt muligheten for end-to-end-transport fra supplikanten til Radius-klienten, fra klienten til Radius-serveren og til slutt fra Radius-serveren til identifikasjonsdatabasen.
Det er på dette siste trinnet at skoen ofte klemmer: ingenting er planlagt for eksempel i LDAP for å transportere utfordringen eller de spesifikke trinnene i MS-CHAP eller MS-CHAP-V2 som plutselig ender utelukkende på lokale Microsoft-identifikasjonsdatabaser for Radius server.
RADIUS-identifikasjonen kan berikes med en autorisasjon, for eksempel for en tilgangsleverandørs klient sin IP-adresse, maksimal tilkoblingstid, inaktivitetstid. Alle disse parametrene er definert av attributter til pakken i RFC-ene, i dette tilfellet for dette eksempelet attributt 8, bedre kjent med sitt "vennlige" navn Framed-IP-adresse, selv om protokollen faktisk bare kjenner tallene og sesjonen -Timeout og Idle-Timeout attributter. Standardattributtene er definert i RFC-ene, de spesifikke attributtene til en leverandør eller VSA (leverandørspesifikke attributter) er multiplekset i attributt 26: hver leverandør tildeles et unikt nummer som lar det identifiseres, en byte av dette attributtet definerer et VSA-nummer , som gjør at hver leverandør kan definere opptil 255 spesifikke attributter for maskinvaren. Radius-serveren tilpasser seg disse "dialektene" ved attributtordbøker ...
Den andre funksjonen til en Radius-server er regnskap, og sikrer både tilgangslogging og fakturering. Definert av forskjellige RFCer, administrert på forskjellige UDP- porter (1646 eller 1813 for de vanligste mens identifikasjon er gjort på porter 1645 eller 1812), er denne funksjonen ofte levert av et annet program eller til og med en annen server.
Regnskap er basert på to hovedtyper av pakker: Accounting Start og Accounting Stop, en økt er definert som intervallet mellom Start og Stop. Accounting Start-pakken sendt av Radius-klienten etter at brukeren faktisk har logget på etter en vellykket identifikasjonsfase inneholder grunnleggende data: brukernavn (men ikke det ubrukelige passordet her), IP-adresse tildelt, dato og tidspunkt for tilkobling, type tilkobling, type tjeneste osv.
Når brukeren kobler fra tjenesten eller Radius-klienten kobler fra ham på grunn av inaktivitet, timeout for tilkobling eller annet, sender denne Radius-klienten en Accounting Stop-pakke med samme øktidentifikator , Radius-serveren kan deretter lukke økten og logge frakoblingen, ofte med et stort antall parametere i Stop-pakken: tilkoblingstid, type bruk, antall pakker og byte utvekslet i henhold til de forskjellige protokollene, og muligens mer konfidensiell informasjon om nettstedene som er besøkt eller inneholdt handler.
Det finnes andre typer regnskapspakker: Mellomliggende (sendes med jevne mellomrom av klienten mellom Start og Stop, nyttig i tilfelle Stop går tapt), På (Radius-klienten har startet) og Av (Radius-klienten vil stoppe), sistnevnte for ordens skyld, er det sjelden at en enhet advarer før den bryter sammen eller krasjer.
For å lette koblingen mellom identifikasjonsfasen og regnskapsfasen (radius-serveren kan ha mottatt hundrevis av andre forespørsler i mellom), blir klasse-attributtet sendt til klienten med Access-Accept-pakken. Radius-klienten blir bedt om å returnere den som i pakken for regnskapsstart. Radius-serveren kan derfor inkludere all denne informasjonen som er nyttig for å opprette forbindelsen mellom en vellykket identifikasjon, ofte ledsaget av en reservasjon av ressurser - kanal, PVC eller IP-adresse - og den faktiske bruken av disse ressursene.
I tilfelle operasjonen avbrytes (det er ingen tilsvarende Accounting Start-pakke etter vellykket identifikasjon), må en mekanisme gjenopprette de reserverte ressursene; de fleste implementeringer bruker en fantomregnskapsrekord for dette . Ressursene som er reservert av identifikasjonen, okkupert av Accounting Start, frigjøres normalt av Accounting Stop-pakken, noe som for eksempel innebærer at en Radius-server bare kan tilordne IP-adresser hvis den også administrerer regnskapsfunksjonen.
Regnskap har også en juridisk funksjon: Internett-tilgang må identifiseres, og alle brukere må kunne spores til minst et konto- eller bankkortnummer, og det er grunnen til at regnskapsfunksjonen alltid er aktivert. Med Internett-leverandører og arkivene: på advokatprovisjon fra en dommer, kan Internett-leverandøren oppgi identifikasjon av en hvilken som helst IP-adresse i et gitt øyeblikk.