RADIE

Den här artikeln handlar om ett nätverksprotokoll för autentisering. För annan användning, se Radie (disambiguation) .
Internetprotokollsvit
Applikationslager
Transportlager
Internetlager
Länklager

Remote Authentication Dial-In User Service ( RADIUS ) är ett nätverksprotokoll som tillhandahåller centraliserad autentisering, auktorisering och redovisning ( AAA ) för användare som ansluter och använder en nätverkstjänst. RADIUS utvecklades av Livingston Enterprises 1991 som ett åtkomstserverautentiserings- och redovisningsprotokoll. Det togs senare in i IEEE 802- och IETF- standarderna.

RADIUS är ett klient/server -protokoll som körs i applikationslagret och kan använda antingen TCP eller UDP . Nätverksåtkomstservrar , som styr åtkomst till ett nätverk, innehåller vanligtvis en RADIUS-klientkomponent som kommunicerar med RADIUS-servern. RADIUS är ofta backend- valet för 802.1X- autentisering. En RADIUS-server är vanligtvis en bakgrundsprocess som körs på UNIX eller Microsoft Windows .

Protokollkomponenter

RADIUS är ett AAA- protokoll (autentisering, auktorisering och redovisning) som hanterar nätverksåtkomst. RADIUS använder två typer av paket för att hantera hela AAA-processen: Access-Request, som hanterar autentisering och auktorisering; och Accounting-Request, som sköter bokföringen. Autentisering och auktorisering definieras i RFC 2865 medan redovisning beskrivs av RFC 2866.

Autentisering och auktorisering

Användaren eller maskinen skickar en begäran till en nätverksåtkomstserver (NAS) för att få tillgång till en viss nätverksresurs med hjälp av åtkomstuppgifter. Inloggningsuppgifterna skickas till NAS-enheten via länklagerprotokollet – till exempel Point-to-Point Protocol (PPP) i fallet med många uppringda eller DSL -leverantörer eller publiceras i ett säkert HTTPS -webbformulär.

I sin tur skickar NAS:en ett RADIUS Access Request- meddelande till RADIUS-servern och begär auktorisation för att ge åtkomst via RADIUS-protokollet.

Denna begäran inkluderar åtkomstuppgifter, vanligtvis i form av användarnamn och lösenord eller säkerhetscertifikat som tillhandahålls av användaren. Dessutom kan begäran innehålla annan information som NAS:en känner till om användaren, såsom dess nätverksadress eller telefonnummer, och information om användarens fysiska anslutningspunkt till NAS:en.

RADIUS-servern kontrollerar att informationen är korrekt med hjälp av autentiseringsscheman som PAP , CHAP eller EAP . Användarens bevis på identifiering verifieras, tillsammans med, valfritt, annan information relaterad till begäran, såsom användarens nätverksadress eller telefonnummer, kontostatus och specifika åtkomstprivilegier för nätverkstjänster. Historiskt sett kontrollerade RADIUS-servrar användarens information mot en lokalt lagrad platt fildatabas. Moderna RADIUS-servrar kan göra detta, eller kan referera till externa källor – vanligtvis SQL , Kerberos , LDAP eller Active Directory- servrar – för att verifiera användarens autentiseringsuppgifter.

RADIUS-autentiserings- och auktoriseringsflöde

RADIUS-servern returnerar sedan ett av tre svar till NAS:en: 1) Access Reject, 2) Access Challenge, eller 3) Access Accept.

Åtkomst Avvisa
Användaren nekas villkorslöst åtkomst till alla begärda nätverksresurser. Orsakerna kan vara underlåtenhet att tillhandahålla bevis på identifiering eller ett okänt eller inaktivt användarkonto.
Åtkomstutmaning
Begär ytterligare information från användaren såsom ett sekundärt lösenord, PIN-kod, token eller kort. Access Challenge används också i mer komplexa autentiseringsdialoger där en säker tunnel upprättas mellan användarmaskinen och Radius Server på ett sätt att åtkomstuppgifterna döljs från NAS:en.
Access Accept
Användaren ges åtkomst. När användaren är autentiserad kontrollerar RADIUS-servern ofta att användaren är behörig att använda den begärda nätverkstjänsten. En given användare kan tillåtas använda ett företags trådlösa nätverk, men inte till exempel dess VPN-tjänst. Återigen kan denna information lagras lokalt på RADIUS-servern eller kan slås upp i en extern källa som LDAP eller Active Directory.

Vart och ett av dessa tre RADIUS-svar kan innehålla ett svar-meddelande-attribut som kan ge en anledning till avslaget, uppmaningen till utmaningen eller ett välkomstmeddelande för att acceptera. Texten i attributet kan skickas vidare till användaren på en returwebbsida.

Behörighetsattribut förmedlas till NAS som anger villkor för åtkomst som ska beviljas. Till exempel kan följande behörighetsattribut inkluderas i en Access-Accept:

  • Den specifika IP-adressen som ska tilldelas användaren
  • Adresspoolen från vilken användarens IP-adress ska väljas
  • Den maximala tiden som användaren kan vara ansluten
  • En åtkomstlista, prioritetskö eller andra begränsningar för en användares åtkomst
  • L2TP- parametrar
  • VLAN- parametrar
  • Quality of Service (QoS) parametrar

När en klient är konfigurerad att använda RADIUS, presenterar alla användare av klienten autentiseringsinformation för klienten. Detta kan vara med en anpassningsbar inloggningsprompt, där användaren förväntas ange sitt användarnamn och lösenord. Alternativt kan användaren använda ett länkramningsprotokoll såsom Point-to-Point Protocol (PPP), som har autentiseringspaket som bär denna information.

När klienten har fått sådan information kan den välja att autentisera med RADIUS. För att göra det skapar klienten en "Access-Request" som innehåller sådana attribut som användarens namn, användarens lösenord, klientens ID och port-ID som användaren har åtkomst till. När ett lösenord finns, döljs det med en metod baserad på RSA Message Digest Algorithm MD5.

Bokföring

RADIUS Redovisningsflöde

Redovisning beskrivs i RFC 2866.

När nätverksåtkomst beviljas användaren av NAS :en skickas en Accounting Start (ett RADIUS Accounting Request-paket som innehåller ett Acct-Status-Type-attribut med värdet "start") av NAS:en till RADIUS-servern för att signalera starten av användarens nätverksåtkomst. "Start"-poster innehåller vanligtvis användarens identifiering, nätverksadress, anknytningspunkt och en unik sessionsidentifierare.

Periodiskt kan Interim Update- poster (ett RADIUS Accounting Request-paket som innehåller ett Acct-Status-Type-attribut med värdet "interim-update") skickas av NAS:en till RADIUS-servern för att uppdatera den om statusen för en aktiv session. "Interims"-poster förmedlar vanligtvis aktuell sessionslängd och information om aktuell dataanvändning.

Slutligen, när användarens nätverksåtkomst stängs, utfärdar NAS:en en slutlig Accounting Stop -post (ett RADIUS Accounting Request-paket som innehåller ett Acct-Status-Type-attribut med värdet "stop") till RADIUS-servern, vilket ger information om den slutliga användningen i termer av tid, överförda paket, överförda data, orsak till frånkoppling och annan information relaterad till användarens nätverksåtkomst.

Vanligtvis skickar klienten paket med redovisningsbegäran tills den tar emot en bekräftelse på redovisningssvar, med ett visst försöksintervall.

Det primära syftet med dessa uppgifter är att användaren kan faktureras i enlighet med detta; uppgifterna används också vanligtvis för statistiska ändamål och för allmän nätverksövervakning.

Roaming

Roaming med en proxy RADIUS AAA-server.

RADIUS används vanligtvis för att underlätta roaming mellan Internetleverantörer , inklusive av:

  • Företag som tillhandahåller en enda global uppsättning referenser som är användbara på många offentliga nätverk;
  • Oberoende, men samarbetande, institutioner som utfärdar sina egna referenser till sina egna användare, som gör att en besökare från en till en annan kan autentiseras av sin heminstitution, till exempel i eduroam .

RADIUS underlättar detta genom att använda sfärer , som identifierar var RADIUS-servern ska vidarebefordra AAA-förfrågningar för bearbetning.

Realms

En sfär läggs vanligtvis till en användares användarnamn och avgränsas med ett "@"-tecken, som liknar ett domännamn för en e-postadress. Detta är känt som postfix- notation för riket. En annan vanlig användning är prefixnotation , vilket innebär att riket läggs till användarnamnet och använder '\' som avgränsare. Moderna RADIUS-servrar tillåter att alla tecken används som sfäravgränsare, även om i praktiken vanligtvis '@' och '\' används.

Realms kan också kombineras med både prefix- och postfix-notation, för att möjliggöra komplicerade roaming-scenarier; till exempel kan somedomain.com\[email protected] vara ett giltigt användarnamn med två världar.

Även om sfärer ofta liknar domäner, är det viktigt att notera att sfärer i själva verket är godtycklig text och inte behöver innehålla riktiga domännamn. Realm-format är standardiserade i RFC 4282, som definierar en Network Access Identifier (NAI) i form av 'user@realm'. I den specifikationen måste "rike"-delen vara ett domännamn. Denna praxis följs dock inte alltid. RFC 7542 ersatte RFC 4282 i maj 2015.

Proxyoperationer

När en RADIUS-server tar emot en AAA-begäran om ett användarnamn som innehåller en sfär, kommer servern att referera till en tabell med konfigurerade sfärer. Om sfären är känd kommer servern sedan att skicka begäran till den konfigurerade hemservern för den domänen. Proxyserverns beteende när det gäller borttagning av sfären från begäran ("stripping") är konfigurationsberoende på de flesta servrar. Dessutom kan proxyservern konfigureras för att lägga till, ta bort eller skriva om AAA-förfrågningar när de får proxy över tid igen.

Proxy Chaining är möjlig i RADIUS och autentiserings-/auktoriserings- och redovisningspaket dirigeras vanligtvis mellan en NAS-enhet och en hemmaserver genom en serie proxyservrar. Några av fördelarna med att använda proxykedjor inkluderar skalbarhetsförbättringar, policyimplementeringar och kapacitetsjusteringar. Men i roaming-scenarier kan NAS, proxyservrar och hemmaserver vanligtvis hanteras av olika administrativa enheter. Därför får förtroendefaktorn bland fullmakterna mer betydelse under sådana interdomänapplikationer. Vidare bidrar avsaknaden av slut-till-änd-säkerhet i RADIUS till det kritiska i förtroendet bland de inblandade ombuden. Proxykedjor förklaras i RFC 2607 .

säkerhet

Roaming med RADIUS utsätter användarna för olika säkerhets- och integritetsproblem. Mer allmänt etablerar vissa roamingpartners en säker tunnel mellan RADIUS-servrarna för att säkerställa att användarnas autentiseringsuppgifter inte kan avlyssnas när de skickas via proxy över internet. Detta är ett problem eftersom MD5-hash inbyggd i RADIUS anses osäker.

Paketstruktur

RADIUS-paketdataformat.

RADIUS transporteras över UDP/IP på portarna 1812 och 1813.

RADIUS- paketdataformatet visas till höger. Fälten överförs från vänster till höger, med början med koden, identifieraren, längden, autentiseringsenheten och attributen.

Tilldelade RADIUS-koder (decimal) inkluderar följande:

Koda Uppdrag
1 Åtkomst-förfrågan
2 Access-Acceptera
3 Åtkomst-Avvisa
4 Bokföring-Begäran
5 Redovisning-Svar
11 Access-Challenge
12 Status-server (experimentell)
13 Status-klient (experimentell)
40 Koppla från-Begäran
41 Koppla bort-ACK
42 Koppla från-NAK
43 CoA-förfrågan
44 CoA-ACK
45 CoA-NAK
255 Reserverad

Identifieringsfältet hjälper till att matcha förfrågningar och svar.

Fältet Längd anger längden på hela RADIUS-paketet inklusive kod, identifierare, längd, autentisering och valfria attributfält.

Authenticator används för att autentisera svaret från RADIUS-servern och används för att kryptera lösenord; dess längd är 16 byte.

Attributvärdepar

RADIUS AVP-layout

RADIUS Attribute Value Pairs (AVP) innehåller data i både begäran och svaret för autentisering, auktorisering och redovisningstransaktioner. Längden på radiepaketet används för att bestämma slutet av AVP:erna.

Leverantörsspecifika attribut

RADIUS är utdragbar; många leverantörer av RADIUS-hårdvara och mjukvara implementerar sina egna varianter med leverantörsspecifika attribut (VSA). Microsoft har publicerat några av sina VSA:er. VSA-definitioner från många andra företag förblir proprietära och/eller ad hoc, men många VSA-ordböcker kan hittas genom att ladda ner källkoden för RADIUS-implementeringar med öppen källkod, till exempel FreeRADIUS .

RFC 2865 tillhandahåller grundläggande kodning som attributet ska följa, inom beskrivningsvärdet i fältet Leverantörslängd är inte explicit utan bör förstås inom en attribut-värdekontext. Denna leverantörslängd är längden på värdet i byte plus 2 byte, dessa två byte räknas för leverantörstyp och leverantörslängd.

Leverantörsspecifika attribut följer denna kodning som används av freeradius-implementering med leverantörsspecifika ordböcker.

26 (1 byte) Längd (1 byte) Leverantörs-ID (4 byte Big Endian) Leverantörstyp/attribut (1Byte) Leverantörens längd (1 byte) = 2 + längden på (värde) Värde

säkerhet

RADIUS-protokollet överför obfuskerade lösenord med hjälp av en delad hemlighet och MD5- hash-algoritmen. Eftersom denna speciella implementering endast ger svagt skydd av användarens autentiseringsuppgifter, bör ytterligare skydd, såsom IPsec- tunnlar eller fysiskt säkrade datacenternätverk, användas för att ytterligare skydda RADIUS-trafiken mellan NAS-enheten och RADIUS-servern. Dessutom är användarens säkerhetsuppgifter den enda delen som skyddas av RADIUS själv, men andra användarspecifika attribut som t.ex. tunnelgrupps-ID:n eller VLAN -medlemskap som skickas över RADIUS kan anses vara känsliga (till hjälp för en angripare) eller privata (tillräckliga för att identifiera individuell kund) information. [ citat behövs ] RadSec - protokollet gör anspråk på att lösa ovannämnda säkerhetsproblem.

Historia

När fler uppringda kunder använde NSFNET skickades en begäran om förslag ut av Merit Network 1991 för att konsolidera deras olika egenutvecklade autentiserings-, auktoriserings- och redovisningssystem. Bland de tidiga respondenterna fanns Livingston Enterprises och en tidig version av RADIUS skrevs efter ett möte. Den tidiga RADIUS-servern installerades på ett UNIX- operativsystem . Livingston Enterprises förvärvades av Lucent och tillsammans med Merit togs steg för att få industrins acceptans för RADIUS som ett protokoll. Båda företagen erbjöd en RADIUS-server utan kostnad. 1997 publicerades RADIUS som RFC 2058 och RFC 2059, nuvarande versioner är RFC 2865 och RFC 2866.

Den ursprungliga RADIUS-standarden angav att RADIUS är tillståndslös och ska köras över User Datagram Protocol (UDP). För autentisering var det tänkt att RADIUS skulle stödja Password Authentication Protocol (PAP) och Challenge-Handshake Authentication Protocol (CHAP) över Point-to-Point Protocol . Lösenord döljs genom att ta MD5 -hash för paketet och en delad hemlighet, och sedan XORing den hash med lösenordet. Den ursprungliga RADIUS gav också mer än 50 attribut-värde-par, med möjlighet för leverantörer att konfigurera sina egna par.

Valet av hop-by-hop-säkerhetsmodellen, snarare än end-to-end-kryptering , innebar att om flera proxy RADIUS-servrar används måste varje server undersöka, utföra logik och skicka vidare all data i en begäran. Detta exponerar data som lösenord och certifikat vid varje hopp. RADIUS-servrar hade inte heller möjlighet att stoppa åtkomst till resurser när en auktorisering hade utfärdats. Efterföljande standarder som RFC 3576 och dess efterföljare RFC 5176 gjorde det möjligt för RADIUS-servrar att dynamiskt ändra en användares auktorisering eller att koppla bort en användare helt.

Nu finns det flera kommersiella och öppen källkod RADIUS-servrar. Funktioner kan variera, men de flesta kan slå upp användarna i textfiler, LDAP- servrar, olika databaser etc. Bokföringsposter kan skrivas till textfiler, olika databaser, vidarebefordras till externa servrar etc. SNMP används ofta för fjärrövervakning och hålla vid liv kontroll av en RADIUS-server. RADIUS- proxyservrar används för centraliserad administration och kan skriva om RADIUS-paket i farten av säkerhetsskäl, eller för att konvertera mellan säljardialekter.

Diameterprotokollet var tänkt som ersättning för RADIUS . Även om båda är protokoll för autentisering, auktorisering och redovisning (AAA), har användningsfallen för de två protokollen sedan dess skiljt sig åt. Diameter används till stor del i 3G- utrymmet. RADIUS används på annat håll. En av de största hindren för att Diameter ska ersätta RADIUS är att switchar och accesspunkter vanligtvis implementerar RADIUS, men inte Diameter. Diameter använder SCTP eller TCP medan RADIUS vanligtvis använder UDP som transportlager . Från och med 2012 kan RADIUS även använda TCP som transportlager med TLS för säkerhet.

Standarddokumentation

RADIUS-protokollet definieras för närvarande i följande IETF RFC-dokument.

RFC Titel Publiceringsdatum Relaterad artikel Relaterade RFC:er Notera
RFC 2058 Användartjänst för fjärrautentisering (RADIUS) januari 1997 RADIE Föråldrad av RFC 2138
RFC 2059 RADIUS Redovisning januari 1997 RADIE Föråldrad av RFC 2139
RFC 2138 Användartjänst för fjärrautentisering (RADIUS) april 1997 RADIE Föråldrad av RFC 2865
RFC 2139 RADIUS Redovisning april 1997 RADIE Föråldrad av RFC 2866
RFC 2548 Microsoft-leverantörsspecifika RADIUS-attribut mars 1999 RADIE
RFC 2607 Proxykedja och policyimplementering i roaming juni 1999
RFC 2618 RADIUS Authentication Client MIB Ledningsinformationsbas Föråldrad av RFC 4668
RFC 2619 RADIUS Authentication Server MIB Ledningsinformationsbas Föråldrad av RFC 4669
RFC 2620 RADIUS Accounting Client MIB juni 1999 Ledningsinformationsbas Föråldrad av RFC 4670
RFC 2621 RADIUS Accounting Server MIB juni 1999 Ledningsinformationsbas Föråldrad av RFC 4671
RFC 2809 Implementering av L2TP Obligatorisk Tunneling via RADIUS april 2000
RFC 2865 Användartjänst för fjärrautentisering (RADIUS) juni 2000 RADIE Uppdaterad av RFC 2868, RFC 3575, RFC 5080 Den här standarden beskriver RADIUS-autentisering och auktorisering mellan en Network Access Server (NAS) och en delad RADIUS-autentiseringsserver. Detta protokoll används också för att överföra konfigurationsinformation från RADIUS-servern till NAS:en.
RFC 2866 RADIUS Redovisning juni 2000 RADIE Denna standard beskriver hur redovisningsinformation överförs från NAS:en till en delad RADIUS-redovisningsserver.
RFC 2867 RADIUS Redovisningsändringar för stöd för tunnelprotokoll juni 2000 RADIE Uppdaterar RFC 2866
RFC 2868 RADIUS-attribut för stöd för tunnelprotokoll juni 2000 Uppdaterar RFC 2865
RFC 2869 RADIUS-förlängningar juni 2000 Uppdaterad av RFC 3579, RFC 5080
RFC 2882 Krav på nätverksåtkomstservrar: Utökad RADIUS-praxis juli 2000
RFC 3162 RADIUS och IPv6 augusti 2001
RFC 3575 IANA Överväganden för RADIUS juli 2003
RFC 3576 Dynamiska auktoriseringstillägg till RADIUS juli 2003 Föråldrad av RFC 5176
RFC 3579 RADIUS Stöd för EAP september 2003 Extensible Authentication Protocol Uppdaterar RFC 2869
RFC 3580 Riktlinjer för användning av IEEE 802.1X RADIUS september 2003 802.1X
RFC 4014 Alternativ för RADIUS-attribut för informationsalternativet DHCP-reläagent februari 2005
RFC 4372 Debiterbar användaridentitet januari 2006
RFC 4590 RADIUS-tillägg för Digest-autentisering juli 2006 Föråldrad av RFC 5090
RFC 4668 RADIUS Authentication Client MIB för IPv6 augusti 2006 Ledningsinformationsbas
RFC 4669 RADIUS Authentication Server MIB för IPv6 augusti 2006 Ledningsinformationsbas
RFC 4670 RADIUS Accounting Client MIB för IPv6 augusti 2006 Ledningsinformationsbas
RFC 4671 RADIUS Accounting Server MIB för IPv6 augusti 2006 Ledningsinformationsbas
RFC 4675 RADIUS-attribut för virtuellt LAN och Priority Support september 2006
RFC 4679 DSL-forums leverantörsspecifika RADIUS-attribut september 2006
RFC 4818 RADIUS Delegated-IPv6-Prefix Attribut april 2007
RFC 4849 RADIUS-filterregelattribut april 2007
RFC 5080 Vanliga RADIUS-implementeringsproblem och föreslagna korrigeringar december 2007 Uppdaterar RFC 3579
RFC 5090 RADIUS-tillägg för Digest-autentisering februari 2008
RFC 5176 Dynamiska auktoriseringstillägg till RADIUS januari 2008
RFC 5607 RADIUS-auktorisering för NAS-hantering juli 2009
RFC 5997 Användning av Status-Server-paket i RADIUS-protokollet augusti 2010 Uppdaterar RFC 2866
RFC 6158 RADIUS designriktlinjer mars 2011
RFC 6218 Cisco leverantörsspecifika RADIUS-attribut för leverans av nyckelmaterial april 2011
RFC 6421 Krypto-agility-krav för fjärrautentisering för uppringd användartjänst (RADIUS) november 2011
RFC 6613 RADIUS över TCP maj 2012 Experimentell
RFC 6614 Transport Layer Security (TLS)-kryptering för RADIUS maj 2012 Experimentell
RFC 6911 RADIUS-attribut för IPv6-åtkomstnätverk april 2013 Standardspår
RFC 6929 Remote Authentication Dial-In User Service (RADIUS) Protocol Extensions april 2013 Uppdateringar RFC 2865, RFC 3575, RFC 6158
RFC 7360 Datagram Transport Layer Security (DTLS) som ett transportlager för RADIUS september 2014 Experimentell
RFC 7585 Dynamic Peer Discovery för RADIUS/TLS och RADIUS/DTLS Baserat på Network Access Identifier (NAI) oktober 2015 Experimentell
RFC 8044 Datatyper i RADIUS januari 2017 Uppdateringar: 2865, 3162, 4072, 6158, 6572, 7268
RFC 8559 Dynamisk auktoriseringsproxying i RADIUS-protokollet april 2019 Standardspår

Se även

Bibliografi

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=RADIUS&oldid=1134635324 "