Udvidelig godkendelsesprotokol - Extensible Authentication Protocol

Extensible Authentication Protocol ( EAP ) er en godkendelsesramme, der ofte bruges i netværks- og internetforbindelser. Det er defineret i RFC 3748, der gjorde RFC 2284 forældet og opdateres af RFC 5247. EAP er en godkendelsesramme til levering af transport og brug af materiale og parametre genereret af EAP -metoder. Der er mange metoder defineret af RFC'er, og der findes en række leverandørspecifikke metoder og nye forslag. EAP er ikke en trådprotokol; i stedet definerer det kun oplysningerne fra grænsefladen og formaterne. Hver protokol, der bruger EAP, definerer en måde at indkapsle af brugerens EAP -meddelelser inden for protokollens meddelelser.

EAP er i vid udstrækning. I IEEE 802.11 (WiFi) har WPA- og WPA2 -standarderne f.eks. Vedtaget IEEE 802.1X (med forskellige EAP -typer) som den kanoniske godkendelsesmekanisme.

Metoder

EAP er en godkendelsesramme, ikke en specifik godkendelsesmekanisme. Det giver nogle fælles funktioner og forhandlinger om godkendelsesmetoder kaldet EAP -metoder. Der er i øjeblikket omkring 40 forskellige metoder defineret. Metoder defineret i IETF RFC'er inkluderer EAP-MD5, EAP-POTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, EAP-AKA og EAP-AKA '. Derudover findes der en række leverandørspecifikke metoder og nye forslag. Almindeligt anvendte moderne metoder, der er i stand til at fungere i trådløse netværk, omfatter EAP-TLS, EAP-SIM, EAP-AKA, LEAP og EAP-TTLS. Krav til EAP -metoder, der bruges til trådløs LAN -godkendelse, er beskrevet i RFC 4017. Listen over type- og pakkekoder, der bruges i EAP, er tilgængelig fra IANA EAP -registreringsdatabasen.

Standarden beskriver også de betingelser, hvorunder AAA -nøglekontrolkravene beskrevet i RFC 4962 kan opfyldes.

Lightweight Extensible Authentication Protocol (LEAP)

Hovedartikel: Lightweight Extensible Authentication Protocol

Metoden Lightweight Extensible Authentication Protocol (LEAP) blev udviklet af Cisco Systems før IEEE -ratificeringen af 802.11i -sikkerhedsstandarden. Cisco distribuerede protokollen gennem CCX (Cisco Certified Extensions) som en del af at få 802.1X og dynamisk WEP -adoption ind i branchen i mangel af en standard. Der er ingen indbygget support til LEAP i noget Windows -operativsystem , men det understøttes i vid udstrækning af tredjeparts klientsoftware, der oftest følger med WLAN (trådløst LAN) -enheder. LEAP- understøttelse til Microsoft Windows 7 og Microsoft Windows Vista kan tilføjes ved at downloade et klient-tilføjelsesprogram fra Cisco, der understøtter både LEAP og EAP-FAST. På grund af den brede anvendelse af LEAP i netværksindustrien gør mange andre WLAN -leverandører krav på støtte til LEAP.

LEAP bruger en modificeret version af MS-CHAP , en godkendelsesprotokol , hvor brugeroplysninger ikke er stærkt beskyttet og let kompromitteret; et exploit -værktøj kaldet ASLEAP blev udgivet i begyndelsen af ​​2004 af Joshua Wright. Cisco anbefaler, at kunder, der absolut skal bruge LEAP, kun gør det med tilstrækkeligt komplekse adgangskoder, selvom komplekse adgangskoder er vanskelige at administrere og håndhæve. Ciscos nuværende anbefaling er at bruge nyere og stærkere EAP-protokoller som EAP-FAST, PEAP eller EAP-TLS.

EAP Transport Layer Security (EAP-TLS)

EAP Transport Layer Security (EAP-TLS), defineret i RFC 5216, er en åben IETF- standard, der anvender Transport Layer Security (TLS) -protokollen og understøttes godt af trådløse leverandører. EAP-TLS er den originale, standard trådløse LAN EAP-godkendelsesprotokol.

EAP-TLS betragtes stadig som en af ​​de mest sikre EAP-standarder, der findes, selvom TLS kun giver stærk sikkerhed, så længe brugeren forstår potentielle advarsler om falske legitimationsoplysninger og understøttes universelt af alle producenter af hardware og software til trådløst LAN. Indtil april 2005 var EAP-TLS de eneste leverandører af EAP-typen, der behøvede at certificere et WPA- eller WPA2-logo. Der er klient- og serverimplementeringer af EAP-TLS i 3Com, Apple, Avaya , Brocade Communications, Cisco, Enterasys Networks, Fortinet, Foundry, Hirschmann, HP, Juniper, Microsoft og open source-operativsystemer. EAP- TLS understøttes indbygget i Mac OS X 10.3 og nyere, wpa_supplicant , Windows 2000 SP4, Windows XP og nyere, Windows Mobile 2003 og nyere, Windows CE 4.2 og Apples iOS mobile operativsystem.

I modsætning til de fleste TLS-implementeringer af HTTPS , f.eks. På World Wide Web , kræver størstedelen af ​​implementeringerne af EAP-TLS gensidig godkendelse ved hjælp af X.509- certifikater på klientsiden uden at give mulighed for at deaktivere kravet, selvom standarden ikke kræver deres brug. Nogle har identificeret dette for at have potentiale til dramatisk at reducere vedtagelsen af ​​EAP-TLS og forhindre "åbne", men krypterede adgangspunkter. Den 22. august 2012 tilføjede hostapd (og wpa_supplicant) support i sit Git- depot til en UNAUTH-TLS-leverandørspecifik EAP-type (ved hjælp af hostapd/wpa_supplicant-projektet RFC 5612 Private Enterprise Number) og den 25. februar 2014 tilføjede support til WFA- UNAUTH-TLS leverandørspecifik EAP-type (ved hjælp af Wi-Fi Alliance Private Enterprise Number), som kun udfører servergodkendelse. Dette ville muliggøre situationer meget som HTTPS, hvor et trådløst hotspot tillader gratis adgang og ikke godkender stationsklienter, men stationsklienter ønsker at bruge kryptering ( IEEE 802.11i-2004 dvs. WPA2 ) og potentielt godkende det trådløse hotspot. Der har også været forslag om at bruge IEEE 802.11u til adgangspunkter til at signalere, at de tillader EAP-TLS kun at bruge autentificering på serversiden ved hjælp af standard EAP-TLS IETF-typen i stedet for en leverandørspecifik EAP-type.

Kravet om et certifikat på klientsiden, uanset hvor upopulært det er, er det, der giver EAP-TLS dens godkendelsesstyrke og illustrerer den klassiske bekvemmelighed vs. sikkerhedsafvejning. Med et certifikat på klientsiden er en kompromitteret adgangskode ikke nok til at bryde ind i EAP-TLS-aktiverede systemer, fordi ubudne gæster stadig skal have certifikatet på klientsiden; en adgangskode er faktisk ikke engang nødvendig, da den kun bruges til at kryptere certifikatet på klientsiden til opbevaring. Den højeste tilgængelige sikkerhed er, når "private nøgler" i klientsiden certifikat er placeret i smartkort . Dette er fordi der ikke er nogen måde at stjæle et klientsidecertifikats tilsvarende private nøgle fra et smartkort uden at stjæle selve kortet. Det er mere sandsynligt, at det fysiske tyveri af et smartkort ville blive bemærket (og smartkortet straks tilbagekaldt), end et (typisk) tyveri af en adgangskode ville blive bemærket. Derudover er den private nøgle på et smartkort typisk krypteret ved hjælp af en pinkode, som kun smartkortets ejer kender, og minimerer dets nytteværdi for en tyv, selv før kortet er blevet rapporteret stjålet og tilbagekaldt.

EAP-MD5

EAP-MD5 var den eneste IETF Standards Track-baserede EAP-metode, da den først blev defineret i den originale RFC for EAP, RFC 2284. Den giver minimal sikkerhed; den MD5 hash-funktionen er sårbar over for ordbogsangreb , og ikke understøtter nøglegenerering, hvilket gør det uegnet til brug med dynamisk WEP eller WPA / WPA2 Enterprise. EAP-MD5 adskiller sig fra andre EAP-metoder ved, at den kun giver godkendelse af EAP-peer til EAP-serveren, men ikke gensidig godkendelse. Ved ikke at levere EAP-servergodkendelse er denne EAP-metode sårbar over for angreb i midten i midten. EAP-MD5-understøttelse blev først inkluderet i Windows 2000 og udfaset i Windows Vista .

EAP-beskyttet engangsadgangskode (EAP-POTP)

EAP Protected One-Time Password (EAP-POTP), som er beskrevet i RFC 4793, er en EAP-metode udviklet af RSA Laboratories, der bruger engangskodeord (OTP), f.eks. En håndholdt hardwareenhed eller et hardware- eller softwaremodul kører på en personlig computer for at generere godkendelsesnøgler. EAP-POTP kan bruges til at levere ensidig eller gensidig godkendelse og nøglemateriale i protokoller, der bruger EAP.

EAP-POTP-metoden giver tofaktors brugergodkendelse, hvilket betyder, at en bruger har brug for både fysisk adgang til et token og viden om et personligt identifikationsnummer (PIN) for at udføre godkendelse.

EAP-forhåndsdelt nøgle (EAP-PSK)

EAP Pre-shared key (EAP-PSK), defineret i RFC 4764, er en EAP-metode til gensidig godkendelse og sessionsnøgleudledning ved hjælp af en forhåndsdelt nøgle (PSK). Det giver en beskyttet kommunikationskanal, når gensidig godkendelse lykkes, for begge parter at kommunikere og er designet til godkendelse over usikre netværk som IEEE 802.11.

EAP-PSK er dokumenteret i en eksperimentel RFC, der giver en let og udvidelig EAP-metode, der ikke kræver nogen offentlig nøgle-kryptografi. EAP -metodeprotokoludvekslingen udføres i mindst fire meddelelser.

EAP-adgangskode (EAP-PWD)

EAP-adgangskode (EAP-PWD), defineret i RFC 5931, er en EAP-metode, der bruger en delt adgangskode til godkendelse. Adgangskoden kan være en lav-entropi og kan hentes fra et sæt mulige adgangskoder, f.eks. En ordbog, som er tilgængelig for en angriber. Den underliggende nøgleudveksling er modstandsdygtig over for aktivt angreb, passivt angreb og ordbogsangreb.

EAP-PWD er i basen af ​​Android 4.0 (ICS), det er i FreeRADIUS og Radiator RADIUS-servere, og det er i hostapd og wpa_supplicant.

EAP Tunneled Transport Layer Security (EAP-TTLS)

EAP Tunneled Transport Layer Security (EAP-TTLS) er en EAP-protokol, der udvider TLS . Det blev co-udviklet af Funk Software og Certicom og understøttes bredt på tværs af platforme. Microsoft inkorporerede ikke native support til EAP-TTLS-protokollen i Windows XP , Vista eller 7 . Understøttelse af TTLS på disse platforme kræver software fra tredjeparts Encryption Control Protocol (ECP). Microsoft Windows startede EAP-TTLS-understøttelse med Windows 8 , understøttelse af EAP-TTLS dukkede op i Windows Phone version 8.1 .

Klienten kan, men behøver ikke at blive godkendt via et CA -signeret PKI -certifikat til serveren. Dette forenkler i høj grad installationsproceduren, da der ikke er brug for et certifikat på hver klient.

Når serveren er sikkert godkendt til klienten via sit CA -certifikat og eventuelt klienten til serveren, kan serveren derefter bruge den etablerede sikre forbindelse ("tunnel") til at godkende klienten. Den kan bruge en eksisterende og bredt udbredt godkendelsesprotokol og infrastruktur, der inkorporerer ældre adgangskodemekanismer og godkendelsesdatabaser, mens den sikre tunnel giver beskyttelse mod aflytning og man-in-the-middle angreb . Bemærk, at brugerens navn aldrig overføres i ukrypteret klar tekst, hvilket forbedrer privatlivets fred.

Der findes to forskellige versioner af EAP-TTLS: original EAP-TTLS (alias EAP-TTLSv0) og EAP-TTLSv1. EAP-TTLSv0 er beskrevet i RFC 5281, EAP-TTLSv1 er tilgængelig som et internetudkast.

EAP Internet Key Exchange v. 2 (EAP-IKEv2)

EAP Internet Key Exchange v. 2 (EAP-IKEv2) er en EAP-metode baseret på Internet Key Exchange- protokol version 2 (IKEv2). Det giver gensidig godkendelse og etablering af sessionsnøgle mellem en EAP -peer og en EAP -server. Det understøtter godkendelsesteknikker, der er baseret på følgende typer legitimationsoplysninger:

Asymmetriske nøglepar
Offentlige/private nøglepar, hvor den offentlige nøgle er integreret i et digitalt certifikat , og den tilsvarende private nøgle kun kendes af en enkelt part.
Adgangskoder
Bit-strenge med lav entropi, der er kendt af både serveren og peer.
Symmetriske nøgler
Bit-strenge med høj entropi, der er kendt af både serveren og peer.

Det er muligt at bruge en anden autentificering legitimationsoplysninger (og dermed teknik) i hver retning. For eksempel godkender EAP -serveren sig selv ved hjælp af offentlige/private nøglepar og EAP -peer ved hjælp af symmetrisk nøgle. Især forventes følgende kombinationer at blive brugt i praksis:

EAP-IKEv2 er beskrevet i RFC 5106, og der findes en prototypeimplementering .

EAP Fleksibel godkendelse via Secure Tunneling (EAP-FAST)

Fleksibel godkendelse via Secure Tunneling (EAP-FAST; RFC 4851) er et protokolforslag fra Cisco Systems som erstatning for LEAP . Protokollen var designet til at imødegå svaghederne ved LEAP og samtidig bevare den "lette" implementering. Brug af servercertifikater er valgfri i EAP-FAST. EAP-FAST bruger en Protected Access Credential (PAC) til at etablere en TLS-tunnel, hvor klientoplysninger verificeres.

EAP-FAST har tre faser:

Fase Fungere Beskrivelse Formål
0 In-band-provisionering-giv jævnaldrende en delt hemmelighed, der skal bruges i sikker fase 1-samtale Bruger Authenticated Diffie-Hellman Protocol (ADHP). Denne fase er uafhængig af andre faser; derfor kan enhver anden ordning (in-band eller out-of-band) bruges i fremtiden. Fjern kravet hos klienten om at etablere en hovedhemmelighed, hver gang en klient kræver netværksadgang
1 Tunnel etablering Godkender ved hjælp af PAC og etablerer en tunnelnøgle Nøgleinstitution til at give fortrolighed og integritet under godkendelsesprocessen i fase 2
2 Godkendelse Godkender den jævnaldrende Flere tunnelerede, sikre godkendelsesmekanismer (legitimationsudveksling)

Når automatisk PAC-klargøring er aktiveret, har EAP-FAST en lille sårbarhed, hvor en angriber kan opfange PAC'en og bruge den til at kompromittere brugeroplysninger. Denne sårbarhed reduceres ved manuel PAC -klargøring eller ved at bruge servercertifikater til PAC -klargøringsfasen.

Det er værd at bemærke, at PAC-filen udstedes pr. Bruger. Dette er et krav i RFC 4851 sek 7.4.4, så hvis en ny bruger logger på netværket fra en enhed, skal der først klargøres en ny PAC -fil. Dette er en af ​​grundene til, at det er svært ikke at køre EAP-FAST i usikker anonym provisioning-tilstand. Alternativet er at bruge enhedsadgangskoder i stedet, men derefter valideres enheden på netværket ikke brugeren.

EAP-FAST kan bruges uden PAC-filer, der falder tilbage til normal TLS.

EAP-FAST understøttes indbygget i Apple OS X 10.4.8 og nyere. Cisco leverer et EAP-FAST-modul til Windows Vista og senere operativsystemer, der har en udvidelig EAPHost-arkitektur til nye godkendelsesmetoder og supplikanter.

Tunnel Extensible Authentication Protocol (TEAP)

Tunnel Extensible Authentication Protocol (TEAP; RFC 7170) er en tunnelbaseret EAP-metode, der muliggør sikker kommunikation mellem en peer og en server ved hjælp af Transport Layer Security (TLS) -protokollen til at etablere en gensidigt godkendt tunnel. Inden i tunnelen bruges TLV (Type-Length-Value) objekter til at formidle godkendelsesrelaterede data mellem EAP-peer og EAP-serveren.

Ud over peer -godkendelse tillader TEAP peer at bede serveren om certifikat ved at sende anmodning i PKCS#10 -format, og serveren kan levere certifikat til peer i [rfc: 2315 PKCS#7] -format. Serveren kan også distribuere betroede rodcertifikater til peer i [rfc: 2315 PKCS#7] -format. Begge operationer er indesluttet i de tilsvarende TLV'er og sker på en sikker måde inde i tidligere etablerede TLS -tunneler.

EAP Subscriber Identity Module (EAP-SIM)

EAP Subscriber Identity Module (EAP-SIM) bruges til godkendelse og distribution af sessionsnøgler ved hjælp af abonnentidentitetsmodulet (SIM) fra Global System for Mobile Communications ( GSM ).

GSM -mobilnetværk bruger et abonnentidentitetsmodulkort til at udføre brugergodkendelse. EAP-SIM bruger en SIM-godkendelsesalgoritme mellem klienten og en Authentication, Authorization and Accounting (AAA) -server, der giver gensidig godkendelse mellem klienten og netværket.

I EAP-SIM erstatter kommunikationen mellem SIM-kortet og Autentificeringscenter (AuC) behovet for et forud fastlagt kodeord mellem klienten og AAA-serveren.

A3/A8-algoritmerne køres et par gange med forskellige 128 bit-udfordringer, så der vil være mere 64 bit Kc-er, som vil blive kombineret/blandet for at skabe stærkere nøgler (Kc-er bruges ikke direkte). Manglen på gensidig godkendelse i GSM er også blevet overvundet.

EAP-SIM er beskrevet i RFC 4186.

EAP-godkendelse og nøgleaftale (EAP-AKA)

Extensible Authentication Protocol Method for Universal Mobile Telecommunications System (UMTS) Authentication and Key Agreement (EAP-AKA), er en EAP-mekanisme til godkendelse og distribution af sessionsnøgler ved hjælp af UMTS Subscriber Identity Module ( USIM ). EAP-AKA er defineret i RFC 4187.

EAP Authentication and Key Agreement prime (EAP-AKA ')

EAP-AKA 'variant af EAP-AKA, defineret i RFC 5448, og bruges til ikke-3GPP adgang til et 3GPP kerne netværk. For eksempel via EVDO , WiFi eller WiMax .

EAP Generic Token Card (EAP-GTC)

EAP Generic Token Card, eller EAP-GTC, er en EAP-metode oprettet af Cisco som et alternativ til PEAPv0/EAP-MSCHAPv2 og defineret i RFC 2284 og RFC 3748. EAP-GTC bærer en tekstudfordring fra godkendelsesserveren og et svar genereret af et sikkerhedstoken . PEAP-GTC-godkendelsesmekanismen tillader generisk godkendelse til et antal databaser, såsom Novell Directory Service (NDS) og Lightweight Directory Access Protocol (LDAP), samt brug af en engangsadgangskode .

EAP-krypteret nøgleudveksling (EAP-EKE)

EAP med den krypterede nøgleudveksling , eller EAP-EKE, er en af ​​de få EAP-metoder, der giver sikker gensidig godkendelse ved hjælp af korte adgangskoder og ikke behov for offentlige nøglecertifikater . Det er en udveksling med tre runder, baseret på Diffie-Hellman- varianten af ​​den velkendte EKE-protokol.

EAP-EKE er specificeret i RFC 6124.

Smidig out-of-band-godkendelse til EAP (EAP-NOOB)

Smidig out-of-band-godkendelse til EAP (EAP-NOOB) er en foreslået (igangværende, ikke RFC) generisk bootstrapping-løsning til enheder, der ikke har nogen forudkonfigureret godkendelsesoplysninger, og som endnu ikke er registreret på nogen server. Det er især nyttigt til Internet-of-Things (IoT) gadgets og legetøj, der ikke indeholder oplysninger om nogen ejer, netværk eller server. Godkendelse til denne EAP-metode er baseret på en brugerassisteret out-of-band (OOB) kanal mellem serveren og peer. EAP-NOOB understøtter mange typer OOB-kanaler såsom QR-koder, NFC-tags, lyd osv. Og i modsætning til andre EAP-metoder er protokolsikkerheden blevet verificeret ved formel modellering af specifikationen med ProVerif- og MCRL2- værktøjer.

EAP-NOOB udfører en flygtig elliptisk kurve Diffie-Hellman (ECDHE) over EAP-kanalen i båndet. Brugeren bekræfter derefter denne udveksling ved at overføre OOB -meddelelsen. Brugere kan overføre OOB -meddelelsen fra peer til serveren, når enheden f.eks. Er et smart -tv, der kan vise en QR -kode. Alternativt kan brugerne overføre OOB -meddelelsen fra serveren til peer'en, når f.eks. Enheden, der bliver bootstrapped, er et kamera, der kun kan læse en QR -kode.

Indkapsling

EAP er ikke en trådprotokol; i stedet definerer det kun meddelelsesformater. Hver protokol, der bruger EAP, definerer en måde at indkapsle EAP -meddelelser inden for protokollens meddelelser.

IEEE 802.1X

Hovedartikel: IEEE 802.1X

Indkapslingen af ​​EAP over IEEE 802 er defineret i IEEE 802.1X og kendt som "EAP over LAN" eller EAPOL. EAPOL blev oprindeligt designet til IEEE 802.3 ethernet i 802.1X-2001, men blev præciseret til at passe til andre IEEE 802 LAN-teknologier såsom IEEE 802.11 trådløst og Fiber Distributed Data Interface (ANSI X3T9.5/X3T12, vedtaget som ISO 9314) i 802.1X -2004. EAPOL-protokollen blev også ændret til brug med IEEE 802.1AE (MACsec) og IEEE 802.1AR (Initial Device Identity, IDevID) i 802.1X-2010.

Når EAP påberåbes af en 802.1X-aktiveret netværksadgangsserver (NAS) -enhed, f.eks. Et IEEE 802.11i-2004 trådløst adgangspunkt (WAP), kan moderne EAP-metoder tilvejebringe en sikker godkendelsesmekanisme og forhandle en sikker privat nøgle (parvis Master Key, PMK) mellem klienten og NAS, som derefter kan bruges til en trådløs krypteringssession ved hjælp af TKIP eller CCMP (baseret på AES ) kryptering.

PEAP

Hovedartikel: Protected Extensible Authentication Protocol

Den Protected Extensible Authentication Protocol , også kendt som Protected EAP eller blot PEAP, er en protokol, der indkapsler EAP inden en potentielt krypteret og autentificeret Transport Layer Security (TLS) tunnel . Formålet var at afhjælpe mangler i EAP; EAP antog en beskyttet kommunikationskanal, såsom den, der leveres af fysisk sikkerhed, så faciliteter til beskyttelse af EAP -samtalen blev ikke tilvejebragt.

PEAP blev udviklet i fællesskab af Cisco Systems, Microsoft og RSA Security. PEAPv0 var den version, der fulgte med Microsoft Windows XP og var nominelt defineret i draft-kamath-pppext-peapv0-00 . PEAPv1 og PEAPv2 blev defineret i forskellige versioner af draft-josefsson-pppext-eap-tls-eap . PEAPv1 blev defineret i draft-josefsson-pppext-eap-tls-eap-00 gennem draft-josefsson-pppext-eap-tls-eap-05 , og PEAPv2 blev defineret i versioner, der begyndte med draft-josefsson-pppext-eap-tls- eap-06 .

Protokollen angiver kun kæde af flere EAP -mekanismer og ikke nogen specifik metode. Brug af EAP-MSCHAPv2 og EAP-GTC- metoderne understøttes mest.

RADIUS og diameter

Hovedartikler: RADIUS og diameter (protokol)

Både RADIUS- og Diameter AAA -protokollerne kan indkapsle EAP -meddelelser. De bruges ofte af Network Access Server (NAS) -enheder til at videresende EAP -pakker mellem IEEE 802.1X -endepunkter og AAA -servere for at lette IEEE 802.1X.

PANA

Hovedartikel: Protokol til bærende godkendelse til netværksadgang

Den protokol til Regnskabsmæssig godkendelse for netværksadgang (PANA) er en IP-baseret protokol, der tillader en anordning til at autentificere sig selv med et netværk, der skal gives adgang. PANA vil ikke definere nogen ny godkendelsesprotokol, nøgledistribution, nøgleaftale eller nøgleafledningsprotokoller; til disse formål vil EAP blive brugt, og PANA vil bære EAP -nyttelasten. PANA tillader dynamisk udbydervalg, understøtter forskellige godkendelsesmetoder, er velegnet til roamingbrugere og er uafhængig af linklagsmekanismerne.

OPP

Hovedartikel: Point-to-Point-protokol

EAP var oprindeligt en godkendelsesudvidelse til Point-to-Point Protocol (PPP). PPP har støttet EAP siden EAP blev oprettet som et alternativ til Challenge-Handshake Authentication Protocol (CHAP) og Password Authentication Protocol (PAP), som til sidst blev inkorporeret i EAP. EAP -udvidelsen til PPP blev først defineret i RFC 2284, nu forældet af RFC 3748.

Se også

Referencer

Yderligere læsning

  • "AAA og netværkssikkerhed til mobil adgang. RADIUS, DIAMETER, EAP, PKI og IP -mobilitet". M Nakhjiri. John Wiley and Sons, Ltd.

eksterne links