KAP

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 6. oktober 2014; checks kræver 19 redigeringer .

CHAP ( Challenge Handshake Authentication Protocol ) er en autentificeringsprotokol med indirekte forhandling .  Det er en godkendelsesalgoritme og sørger for transmission af ikke selve brugerens adgangskode, men indirekte information om den. Nodegodkendelse udføres ved en tre-trins forhandlingsprocedure [1] [2] . CHAP-protokollen er meget brugt af forskellige udbydere af netværksadgangsservere og -klienter [3] . Defineret i RFC 1994 .

Sådan virker det

Det er muligt at udskille en cyklus, som består af tre hoveddele [1] :

1. Efter at PPP -forbindelsen er etableret, og begge parter er enige om at oprette forbindelse via CHAP-protokollen, sender autentificeringen en CHAP-pakke til knudepunktet af Challenge-typen, som indeholder den offentlige nøgle .
2. Baseret på den modtagne offentlige nøgle og dens hemmelighed beregner noden en hash ved hjælp af MD5 -hash-algoritmen og sender en CHAP-pakke af typen Response (svar), der indeholder den beregnede hash.
3. Autentificeringsværktøjet sammenligner den modtagne hashværdi med sin egen beregning af den forventede hashværdi. Hvis værdierne matcher, anses godkendelsen for at være vellykket. Hvis værdierne er forskellige, er forbindelsen brudt.

Med forskellige intervaller sender autentikatoren en ny anmodning til noden, og trin 1-3 gentages [4] [5] .

Struktur af CHAP-pakker

Informationsfeltet for PPP - pakker med protokolfelt 0xc223 indkapsler en enkelt CHAP-pakke, der indeholder følgende felter [6] [7] :

• Kode (Kode). Kodefeltet, som er en oktet langt, identificerer CHAP-pakketypen og kan have en af ​​følgende værdier:

1. Udfordring (kald, tjek);
2. Svar (svar);
3. Succes (succes);
4. Fejl (fiasko).

• Identifikator (Identifier). Identifikationsfeltet, som er en oktet langt, tillader yderligere identifikation afhængigt af pakketypen. Deltager i forhandlingerne om anmodning, svar og anerkendelse.

• Længde (Længde). Længde-feltet, to oktetter langt, angiver længden af ​​CHAP-pakken, inklusive alle felter (kode, identifikator, længde og data).

• Data (Data). Længden af ​​datafeltet er nul eller flere oktetter. Indeholder data i det format, der er angivet af kodefeltet.

Arkitekturkrav

1. Længden af ​​hemmeligheden skal være mindst 1 oktet. Hemmeligheden skal helst have omtrent samme længde som hashværdien for den hashfunktion, der bruges (16 oktetter for MD5 ). Dette er nødvendigt for at give en tilstrækkelig stor rækkevidde til hemmeligheden for at beskytte mod gentagelsesangreb [8] .
2. Hver anmodningsværdi skal være globalt og tidsmæssigt unik og fuldstændig uforudsigelig, så en angriber ikke kan narre en node med en forudsigelig fremtidig anmodning og sende et svar til autentificeringen [8] .

Fordele

• CHAP giver beskyttelse mod replay-angreb. En sådan beskyttelse opnås på grund af den stigende værdi af identifikatoren og den variable værdi af den offentlige nøgle [9] .
• Godkendelsesmetoden er afhængig af, at autentificeringsgiveren og peeren kender hemmeligheden , som aldrig sendes over kanalen. Dette er grunden til, at CHAP giver bedre sikkerhed end PAP [9] [10] .
• Selvom autentificering kun er én måde, kan CHAP-forhandlinger udføres i begge retninger ved hjælp af den samme hemmelighed, hvilket giver gensidig autentificering [2] .

Ulemper

• CHAP kræver, at hemmeligheden er tilgængelig i den klare (ukrypterede) form. Irreversibelt krypterede adgangskodedatabaser kan ikke bruges [11] .
• Dårligt anvendelig til store projekter med et stort antal deltagere, da hver hemmelighed skal gemmes i begge ender af kanalen [9] .

Se også

• PAP
• MS-CHAP

Noter

1. ↑ 1 2 Nitish Dalal, Jenny Shah, Khushboo Hisaria, Devesh Jinwala. En sammenlignende analyse af værktøjer til verifikation af sikkerhedsprotokoller  . - 2010. - S. 785 . Arkiveret fra originalen den 23. september 2017.
2. ↑ 1 2 Cisco - PPP KAP  . Arkiveret fra originalen den 24. december 2017.
3. ↑ Microsoft Technet -  KAP . Arkiveret fra originalen den 24. december 2017.
4. ↑ W. Simpson. PPP Challenge Handshake Authentication Protocol (CHAP  ) . - 1996. - S. 2 . Arkiveret fra originalen den 8. marts 2021.
5. ↑ M.W. Youssef, Hazem El-Gendy. Sikring af godkendelse af TCP/IP Layer Two ved at ændre Challenge-Handshake Authentication Protocol  (engelsk)  // Advanced Computing: An International Journal. - 2012. - Marts. — S. 11 . Arkiveret fra originalen den 24. december 2017.
6. ↑ W. Simpson. PPP Challenge Handshake Authentication Protocol (CHAP  ) . - 1996. - S. 6 . Arkiveret fra originalen den 8. marts 2021.
7. ↑ M.W. Youssef, Hazem El-Gendy. Sikring af godkendelse af TCP/IP Layer Two ved at ændre Challenge-Handshake Authentication Protocol  (engelsk)  // Advanced Computing: An International Journal. - 2012. - Marts. — S. 12 . Arkiveret fra originalen den 24. december 2017.
8. ↑ 12 W. Simpson . PPP Challenge Handshake Authentication Protocol (CHAP ) . - 1996. - S. 4 . Arkiveret fra originalen den 8. marts 2021.  
9. ↑ 1 2 3 W. Simpson. PPP Challenge Handshake Authentication Protocol (CHAP  ) . - 1996. - S. 3 . Arkiveret fra originalen den 8. marts 2021.
10. ↑ Microsoft Technet -  PAP . Arkiveret fra originalen den 24. december 2017.
11. ↑ Guy Leduc. Verifikation af to versioner af Challenge Handshake Authentication Protocol (CHAP  ) . - 1999. - Februar. — S. 1 . Arkiveret fra originalen den 24. december 2017.

Litteratur