EAP

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 22. juni 2019; checks kræver 16 redigeringer .

EAP [1] ( engelsk  Extensible Authentication Protocol , Extensible Authentication Protocol) er en autentificeringsramme , der ofte bruges i trådløse netværk og punkt-til-punkt- forbindelser . Formatet blev først beskrevet i RFC 3748 og opdateret i RFC 5247 .

EAP bruges til at vælge en godkendelsesmetode, videregive nøgler og behandle disse nøgler med plug-ins kaldet EAP-metoder . Der er mange EAP-metoder, både defineret med EAP selv og frigivet af individuelle leverandører. EAP definerer ikke linklaget, det definerer kun meddelelsesformatet. Hver protokol, der bruger EAP, har sin egen EAP-meddelelsesindkapslingsprotokol.

EAP er et ganske populært format, det bruges i IEEE 802.11 ( WiFi ), omkring hundrede EAP-metoder fra IEEE 802.1X er blevet vedtaget som officielle godkendelsesmekanismer i WPA- og WPA2-standarderne .

Protokolskema

Der er tre hoveddeltagere i godkendelsesprocessen:

I nogle tilfælde kan godkendelsesserveren og godkendelsesværktøjet være den samme enhed, såsom hjemmeenheder, der bruger EAP-PSK-metoden. Generelt er godkendelsesprocessen som følger:

  1. Klienten sender en EAP-anmodning for at begynde sin godkendelse. Forespørgslen i Type-feltet indeholder information om, hvilken metode der vil blive brugt (EAP-TLS, EAP-PSK osv.). Klienten sender ikke nødvendigvis denne anmodning, f.eks. hvis der ikke kræves godkendelse på den port, som klienten er forbundet til, i dette tilfælde skal klienten sende en pakke med et kodefelt svarende til Start type.
  2. Autentificeringsværktøjet sender et EAP-svar til klienten i tilfælde af en gyldig anmodning fra klienten. Svaret indeholder Type-feltet svarende til Type-feltet i anmodningen.
  3. Godkendelsesværktøjet sender en anmodning til godkendelsesserveren og videregiver information om, hvilken godkendelsesmetode der bruges.
  4. Godkendelsesserveren anmoder om de nødvendige oplysninger fra klienten gennem godkendelsesværktøjet, på hvilket tidspunkt godkendelsesværktøjet faktisk fungerer som en proxy .
  5. Klienten svarer serveren med de anmodede oplysninger. Punkt 4 og 5 gentages, indtil godkendelsesserveren træffer en beslutning om at tillade adgang, nægte eller fejl.
  6. Godkendelsesserveren sender en pakke til godkendelsesværktøjet, der angiver, om godkendelsen er lykkedes eller mislykkedes.
  7. Autentificeringsværktøjet sender en pakke til EAP-klienten med en kode, der svarer til godkendelsesserverens svar (EAP-Success eller EAP-Failure).

Oversigtstabel over EAP-pakkekoder:

Koden Navn Beskrivelse
0 Udefineret Anvendes ikke
en Anmodning Brugt til at starte godkendelsesprocessen af ​​godkendelsesværktøjet, indeholder oplysninger om de understøttede EAP-metoder.
2 Respons Bruges til at bekræfte, at klienten har startet godkendelse.
3 succes Bruges til at rapportere vellykket godkendelse til klienten.
fire Fiasko Bruges til at rapportere godkendelsesfejl til klienten.
5 Igangsætte Bruges af klienten til at "bede" autentificeringen om at begynde godkendelsesprocessen.

Metoder

Fordi EAP er en autentificeringsramme og ikke en specifik mekanisme [2] , giver den en vis generel funktionalitet og godkendelsesmetodeforhandling (EAP-metoder). Omkring 40 forskellige metoder er blevet defineret indtil videre. Normalt er metoder defineret i IETF , for eksempel: EAP-MD5 , EAP-POTP , EAP-GTC , EAP-TLS , EAP-IKEv2 , EAP-SIM , EAP-AKA og EAP-AKA' . Der er også metoder og forslag fra specifikke løsningsudbydere og udstyrsproducenter. Normalt bruges moderne metoder, der kan fungere i trådløse netværk, for eksempel: EAP-TLS , EAP-SIM , EAP-AKA , LEAP og EAP-TTLS . Krav til metoder anvendt i trådløse netværk er beskrevet i RFC 4017 . Denne standard beskriver også under hvilke forhold AAA-nøglehåndteringsmetoden beskrevet i RFC 4962 kan anvendes.

LEAP

Lightweight Extensible Authentication Protocol , en  metode udviklet af Cisco før IEEE ratificerede 802.11i sikkerhedsstandarden [3] . Cisco distribuerede protokollen gennem CCX (Cisco Certified Extensions) som en del af 802.1X -protokollen og dynamisk WEP på grund af manglen på en separat industristandard i branchen. Der er ingen indbygget understøttelse af LEAP-protokollen [4] i operativsystemer i Windows -familien , dog er protokolunderstøttelse udbredt i tredjeparts klientprogrammer (oftest bundtet med trådløst udstyr). LEAP-understøttelse i Windows kan tilføjes ved at installere Cisco-klientsoftware, der understøtter LEAP- og EAP-FAST-protokollerne. Mange andre producenter af WLAN -udstyr understøtter også LEAP-protokollen på grund af dens høje udbredelse.

LEAP bruger en modificeret version af MS-CHAP- protokollen,  en svagt sikker autentificeringsprotokol , hvor bruger- og adgangskodeoplysninger let kompromitteres ; I begyndelsen af ​​2004 skrev Joshua Wright en udnyttelse til LEAP-protokollen kaldet ASLEAP [5] . Hacket er baseret på, at for det første transmitteres alle elementer af anmodningen og svaret, udover password-hashen, ukrypteret eller let beregnet ud fra data, der sendes over netværket. Det betyder, at det vil være nok for en man-in-the-middle- angriber at få en adgangskode-hash for at genautorisere. For det andet er nøglegenerering potentielt svag. Udfyldning af 5 bytes med nuller betyder, at den sidste tast har et nøglemellemrum på 2 16 . Endelig er den samme klartekst krypteret med to nøgler (når du sender hashen til serveren og når du svarer), hvilket betyder at kompleksiteten på 2 56 er nok til at knække begge nøgler. Når angriberen har alle nøglerne, får han en hash af adgangskoden, som er nok til at genautentificere (flere detaljer i MS-CHAP ).

Cisco anbefaler, at kunder, der ikke kan fravælge LEAP, bruger komplekse adgangskoder, selvom komplekse adgangskoder er svære at indtaste, huske og håndhæve kompleksitetskrav. Ciscos seneste anbefaling er at bruge nyere og mere sikre EAP-protokoller såsom EAP-FAST, PEAP eller EAP-TLS.

EAP-TLS

Transport Layer Security , defineret i RFC 5216 , er en åben standard og bruger TLS -protokollen .  Metoden godkender både klienten og serveren (det vil sige, det er en gensidig godkendelsesmetode). Godt understøttet af producenter af trådløst udstyr. EAP-TLS var den første trådløse standardversion af LAN EAP-godkendelsesprotokollen.

EAP-TLS betragtes stadig som en af ​​de mest sikre standarder, forudsat at brugeren forstår risikoen ved at bruge falske legitimationsoplysninger og understøttes af næsten alle producenter af trådløst udstyr og udviklere af netværkssoftware. Før april 2005 var EAP-TLS den eneste metode, der kræves for at blive understøttet for WPA- eller WPA2- certificering [1] .

Indbygget understøttelse af denne metode er tilgængelig i alle operativsystemer i Windows -familien (startende med Windows 2000 SP4 ), Linux og Mac OS X (fra version 10.3).

I modsætning til mange andre implementeringer af TLS , såsom HTTPS , kræver de fleste EAP-TLS-implementeringer et forudinstalleret X.509-certifikat på klienten, uden mulighed for at deaktivere kravet, selvom standarden ikke kræver dette [6] [7] . Dette kan have forhindret spredningen af ​​"åbne" men krypterede trådløse adgangspunkter [6] [7] . I august 2012 tilføjede hostapd og wpa_supplicant understøttelse af UNAUTH-TLS, en indbygget EAP-godkendelsesmetode [8] og den 25. februar 2014 tilføjede understøttelse af WFA-UNAUTH-TLS, en godkendelsesmetode, der kun autentificerer serveren [9] [10 ] . Dette vil give dig mulighed for at arbejde over EAP-TLS på samme måde som over HTTPS , hvor det trådløse adgangspunkt tillader fri forbindelse (det vil sige, det kræver ikke klientgodkendelse), men det krypterer trafikken ( IEEE 802.11i-2004 , dvs. er, WPA2 ) og tillader pass-godkendelse, hvis det er nødvendigt. Standarderne indeholder også forslag til brug af IEEE 802.11u ved adgangspunkter til at signalere tilgængeligheden af ​​en EAP-TLS-metode, der kun autentificerer serveren ved hjælp af standard IETF EAP-TLS-protokollen, snarere end en tredjeparts EAP-metode [11] .

Kravet om et forudinstalleret certifikat på klientsiden er en af ​​årsagerne til den høje sikkerhed ved EAP-TLS-metoden og et eksempel på at ofre bekvemmelighed til fordel for sikkerhed. For at bryde EAP-TLS er det ikke nok at kompromittere brugerens adgangskode; for et vellykket angreb skal angriberen også tage det klientcertifikat, der svarer til brugeren, i besiddelse. Den bedste sikkerhed kan opnås ved at gemme klientcertifikater i smart cards . [12]

EAP-TTLS

Tunneled Transport Layer Security (Transport Layer Security through the Tunnel), en EAP-metode, der udvider TLS-metodens muligheder. Det blev udviklet af Funk Software og Certicom og er ret godt understøttet på de fleste platforme (Windows siden version 8 og Windows Mobile siden version 8.1 [13] [14] ).

Klienten kan (men er ikke forpligtet til) godkendes af serveren ved hjælp af et PKI-certifikat underskrevet af CA. Den valgfri klientgodkendelse forenkler opsætningsproceduren betydeligt, da der ikke er behov for at generere og installere et individuelt certifikat for hver af dem.

Efter at serveren er autentificeret af klienten ved hjælp af et certifikat signeret af CA og eventuelt af klient-serveren, kan serveren bruge den resulterende sikre forbindelse (tunnel) til yderligere at godkende klienten. Tunnelen tillader brug af autentificeringsprotokoller designet til kanaler, der ikke er beskyttet mod MITM- angreb og mod "aflytning". Ved brug af EAP-TTLS-metoden transmitteres ingen af ​​de oplysninger, der bruges til autentificering, i det klare, hvilket gør det endnu sværere at hacke.

EAP-PSK

Pre-Shared Key , en metode defineret i RFC 4764 , der bruger en foruddelt nøgle til gensidig godkendelse og udveksling af sessionsnøgler . Metoden er designet til at fungere på usikre netværk såsom IEEE 802.11 og, hvis den godkendes, giver den en sikker tovejsforbindelse mellem klienten og adgangspunktet.

EAP-PSK er dokumenteret i en eksperimentel RFC og giver en let og udvidelsesbar EAP-metode, der ikke bruger asymmetrisk kryptering . Denne metode kræver fire beskeder (det mindst mulige antal) til gensidig godkendelse.

Noter

  1. ↑ 1 2 Forståelse af de opdaterede WPA- og WPA2-standarder . techrepublic.com. Arkiveret fra originalen den 31. december 2007.
  2. RFC 3748 . Dato for adgang: 23. december 2014. Arkiveret fra originalen 8. januar 2015.
  3. George Ou. Ultimativ trådløs sikkerhedsguide: En introduktion til LEAP-godkendelse // TechRepublic: Online Magazine. – 2007.
  4. Oversigt over FreeRADIUS Community EAP . Dato for adgang: 23. december 2014. Arkiveret fra originalen 29. december 2014.
  5. Dan Jones. Se før du springer (1. oktober 2003). Arkiveret fra originalen den 9. februar 2008.
  6. ↑ 12 Byrd , Christopher. "Open Secure Wireless (link utilgængeligt) (5. maj 2010). Arkiveret fra originalen den 12. december 2013. 
  7. ↑ 1 2 Certifikat_request-meddelelsen inkluderes, når serveren ønsker, at peeren skal autentificere sig selv via offentlig nøgle. Selvom EAP-serveren SKAL kræve peer-godkendelse, er dette ikke obligatorisk, da der er omstændigheder, hvor peer-godkendelse ikke vil være nødvendig (f.eks. nødtjenester, som beskrevet i [UNAUTH ), eller hvor peeren vil godkende på anden vis. ] (marts 2008). Dato for adgang: 24. december 2014. Arkiveret fra originalen 25. december 2014.
  8. Tilføj UNAUTH-TLS-leverandørspecifik EAP-type (downlink) . Arkiveret fra originalen den 13. februar 2013. 
  9. HS 2.0R2: Tilføj WFA-server-kun EAP-TLS peer-metode (downlink) . Arkiveret fra originalen den 30. september 2014. 
  10. HS 2.0R2: Tilføj WFA-server-kun EAP-TLS peer-metode (downlink) . Arkiveret fra originalen den 30. september 2014. 
  11. Byrd, Christopher. Åbn Secure Wireless 2.0 (utilgængeligt link) (1. november 2011). Arkiveret fra originalen den 26. november 2013. 
  12. Rand Morimoto; Kenton Gardinier, Michael Noel og Joe Coca. Microsoft Exchange Server 2003 frigivet . - 2003. - S.  244 . — ISBN ISBN 978-0-672-32581-6 .
  13. 802.1x / EAP TTLS-understøttelse? - Windows Phone Central-fora . Hentet 26. december 2014. Arkiveret fra originalen 15. august 2014.
  14. Enterprise Wi-Fi-godkendelse (EAP) . Dato for adgang: 26. december 2014. Arkiveret fra originalen 26. december 2014.