โปรโตคอลการตรวจสอบสิทธิ์แบบขยายได้ ( EAP ) เป็นเฟรมเวิร์กการตรวจสอบสิทธิ์ที่ใช้บ่อยในการเชื่อมต่อเครือข่ายและอินเทอร์เน็ต EAP ได้รับการกำหนดไว้ในRFC  3748ซึ่งทำให้RFC 2284ล้าสมัย และได้รับการปรับปรุงโดยRFC 5247 EAP เป็นเฟรมเวิร์กการตรวจสอบสิทธิ์สำหรับการขนส่งและการใช้งานข้อมูลและพารามิเตอร์ที่สร้างขึ้นโดยวิธีการของ EAP มีวิธีการมากมายที่กำหนดไว้ใน RFC และยังมีวิธีการเฉพาะของผู้จำหน่ายและข้อเสนอใหม่ๆ อีกมากมาย EAP ไม่ใช่โปรโตคอลแบบใช้สายแต่กำหนดเฉพาะข้อมูลจากอินเทอร์เฟซและรูปแบบเท่านั้น แต่ละโปรโตคอลที่ใช้ EAP จะกำหนดวิธีการห่อหุ้มข้อความ EAP โดยผู้ใช้ภายในข้อความของโปรโตคอลนั้นๆ   

EAP มีการใช้งานอย่างแพร่หลาย ตัวอย่างเช่น ใน มาตรฐาน IEEE 802.11 (Wi-Fi) มาตรฐาน WPA และ WPA2 ได้นำมาตรฐาน IEEE 802.1X (ที่มี EAP ประเภทต่างๆ) มาใช้เป็นกลไกการตรวจสอบสิทธิ์หลัก

EAP เป็นกรอบการตรวจสอบสิทธิ์ ไม่ใช่กลไกการตรวจสอบสิทธิ์เฉพาะ^{[ 1 ]} EAP มีฟังก์ชันทั่วไปและการเจรจาต่อรองวิธีการตรวจสอบสิทธิ์ที่เรียกว่าวิธีการ EAP ปัจจุบันมีวิธีการที่กำหนดไว้ประมาณ 40 วิธี วิธีการที่กำหนดไว้ในIETF RFCs ได้แก่ EAP-MD5, EAP-POTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM, EAP-AKA และ EAP-AKA' นอกจากนี้ยังมีวิธีการเฉพาะของผู้จำหน่ายและข้อเสนอใหม่ๆ อีกจำนวนหนึ่ง วิธีการที่ใช้กันทั่วไปในปัจจุบันที่สามารถทำงานในเครือข่ายไร้สายได้ ได้แก่ EAP-TLS, EAP-SIM, EAP-AKA, LEAPและ EAP-TTLS ข้อกำหนดสำหรับวิธีการ EAP ที่ใช้ใน การตรวจสอบสิทธิ์ LAN ไร้สายมีอธิบายไว้ในRFC 4017รายชื่อประเภทและรหัสแพ็กเก็ตที่ใช้ใน EAP สามารถดูได้จาก IANA EAP Registry ^{[ 2 ]} 

มาตรฐานนี้ยังอธิบายถึงเงื่อนไขที่สามารถปฏิบัติ ตามข้อกำหนดการจัดการคีย์ AAA ที่อธิบายไว้ใน RFC 4962 ได้อีกด้วย 

วิธี การ Lightweight Extensible Authentication Protocol (LEAP) ได้รับการพัฒนาโดยCisco Systemsก่อนที่IEEEจะให้การรับรองมาตรฐานความปลอดภัย802.11i ^{[ 3 ]} Cisco ได้เผยแพร่โปรโตคอลผ่าน CCX (Cisco Certified Extensions) ซึ่งเป็นส่วนหนึ่งของการนำ 802.1X และWEP แบบไดนามิกมาใช้ในอุตสาหกรรมในขณะที่ยังไม่มีมาตรฐาน ระบบปฏิบัติการ Windowsไม่มีการรองรับ LEAP โดยตรงแต่ได้รับการสนับสนุนอย่างกว้างขวางจากซอฟต์แวร์ไคลเอ็นต์ของบุคคลที่สาม ซึ่งส่วนใหญ่มักรวมอยู่ในอุปกรณ์ WLAN (เครือข่ายไร้สาย) สามารถเพิ่มการรองรับ LEAPสำหรับ Microsoft Windows 7 และ Microsoft Windows Vista ได้โดยการดาวน์โหลดส่วนเสริมไคลเอ็นต์จาก Cisco ซึ่งให้การสนับสนุนทั้ง LEAP และ EAP-FAST เนื่องจากการใช้งาน LEAP อย่างกว้างขวางในอุตสาหกรรมเครือข่าย ผู้จำหน่าย WLAN อื่นๆ จำนวนมากจึงอ้างว่ารองรับ LEAP

LEAP ใช้ MS-CHAPเวอร์ชันดัดแปลง ซึ่ง เป็น โปรโตคอล การตรวจสอบสิทธิ์ที่ข้อมูลประจำตัวของผู้ใช้ไม่ได้รับการปกป้องอย่างแน่นหนาและถูกบุกรุกได้ง่าย เครื่องมือโจมตีที่เรียกว่า ASLEAP ได้รับการเผยแพร่ในช่วงต้นปี 2547 โดย Joshua Wright ^{[ 4 ]} Cisco แนะนำให้ลูกค้าที่จำเป็นต้องใช้ LEAP ใช้เฉพาะรหัสผ่านที่ซับซ้อนเพียงพอเท่านั้น แม้ว่ารหัสผ่านที่ซับซ้อนจะจัดการและบังคับใช้ได้ยากก็ตาม คำแนะนำปัจจุบันของ Cisco คือให้ใช้โปรโตคอล EAP ที่ใหม่กว่าและแข็งแกร่งกว่า เช่น EAP-FAST, PEAPหรือ EAP-TLS

EAP Transport Layer Security (EAP-TLS) ซึ่งกำหนดไว้ในRFC 5216เป็นมาตรฐานเปิด ของ IETF ที่ใช้ โปรโตคอล Transport Layer Security (TLS) และได้รับการสนับสนุนอย่างดีจากผู้ผลิตอุปกรณ์ไร้สาย EAP-TLS เป็นโปรโตคอลการตรวจสอบสิทธิ์ EAP สำหรับเครือข่าย LAN ไร้สายที่เป็นมาตรฐานดั้งเดิม  

EAP-TLS ยังคงถือเป็นหนึ่งในมาตรฐาน EAP ที่ปลอดภัยที่สุดที่มีอยู่ แม้ว่า TLS จะให้ความปลอดภัยที่แข็งแกร่งก็ต่อเมื่อผู้ใช้เข้าใจคำเตือนที่อาจเกิดขึ้นเกี่ยวกับข้อมูลประจำตัวที่ไม่ถูกต้อง และได้รับการสนับสนุนอย่างกว้างขวางจากผู้ผลิตฮาร์ดแวร์และซอฟต์แวร์ LAN ไร้สายทุกราย จนถึงเดือนเมษายน 2548 EAP-TLS เป็นประเภท EAP เพียงประเภทเดียวที่ผู้จำหน่ายจำเป็นต้องรับรองสำหรับโลโก้ WPA หรือ WPA2 ^{[ 5 ]}มีการใช้งาน EAP-TLS ทั้งฝั่งไคลเอ็นต์และเซิร์ฟเวอร์ใน 3Com, Apple, Avaya , Brocade Communications, Cisco, Enterasys Networks, Fortinet, Foundry, Hirschmann, HP, Juniper, Microsoft และระบบปฏิบัติการโอเพนซอร์ส EAP- TLSได้รับการสนับสนุนโดยตรงใน Mac OS X 10.3 ขึ้นไป, wpa_supplicant , Windows 2000 SP4, Windows XP ขึ้นไป, Windows Mobile 2003 ขึ้นไป, Windows CE 4.2 และระบบปฏิบัติการมือถือ iOS ของ Apple

แตกต่างจากการใช้งาน TLS ของHTTPS ส่วนใหญ่ เช่น บนเวิลด์ไวด์เว็บการใช้งาน EAP-TLS ส่วนใหญ่ต้องการการตรวจสอบสิทธิ์ร่วมกันโดยใช้ ใบรับรอง X.509 ฝั่งไคลเอ็นต์ โดยไม่มีตัวเลือกให้ปิดใช้งานข้อกำหนดนี้ แม้ว่ามาตรฐานจะไม่ได้บังคับใช้ก็ตาม^{[ 6 ] [ 7 ]}บางคนระบุว่าสิ่งนี้มีศักยภาพที่จะลดการใช้งาน EAP-TLS ลงอย่างมากและป้องกันจุดเข้าถึงแบบ "เปิด" แต่เข้ารหัส^{[ 6 ] [ 7 ]}เมื่อวันที่ 22 สิงหาคม 2555 hostapd (และ wpa_supplicant) ได้เพิ่มการสนับสนุนใน ที่เก็บ Gitสำหรับประเภท EAP เฉพาะผู้จำหน่าย UNAUTH-TLS (โดยใช้หมายเลของค์กรส่วนตัวRFC 5612 ของโครงการ hostapd/wpa_supplicant) ^{[ 8 ]}และเมื่อวันที่ 25 กุมภาพันธ์ 2557 ได้เพิ่มการสนับสนุนสำหรับประเภท EAP เฉพาะผู้จำหน่าย WFA-UNAUTH-TLS (โดยใช้ หมายเลของค์กรส่วนตัว ของ Wi-Fi Alliance ) ^{[ 9 ] [ 10 ]}ซึ่งทำการตรวจสอบสิทธิ์เซิร์ฟเวอร์เท่านั้น สิ่งนี้จะช่วยให้สามารถรับมือกับสถานการณ์ต่างๆ ได้เช่นเดียวกับ HTTPS ซึ่งฮอตสปอตไร้สายอนุญาตให้เข้าถึงได้ฟรีและไม่ตรวจสอบสิทธิ์ไคลเอนต์สถานี แต่ไคลเอนต์สถานีต้องการใช้การเข้ารหัส ( IEEE 802.11i-2004เช่นWPA2 ) และอาจตรวจสอบสิทธิ์ฮอตสปอตไร้สายด้วย นอกจากนี้ ยังมีข้อเสนอให้ใช้IEEE 802.11uสำหรับจุดเชื่อมต่อเพื่อส่งสัญญาณว่าอนุญาตให้ใช้ EAP-TLS โดยใช้การตรวจสอบสิทธิ์ฝั่งเซิร์ฟเวอร์เท่านั้น โดยใช้ประเภท EAP-TLS IETF มาตรฐานแทนประเภท EAP เฉพาะของผู้จำหน่าย^{[ 11 ]} 

อย่างไรก็ตาม ข้อกำหนดสำหรับใบรับรองฝั่งไคลเอ็นต์ แม้ว่าจะไม่เป็นที่นิยมก็ตาม เป็นสิ่งที่ทำให้ EAP-TLS มีความแข็งแกร่งในการตรวจสอบสิทธิ์ และแสดงให้เห็นถึงการแลกเปลี่ยนระหว่างความสะดวกสบายและความปลอดภัยแบบคลาสสิก ด้วยใบรับรองฝั่งไคลเอ็นต์ รหัสผ่านที่ถูกบุกรุกไม่เพียงพอที่จะเจาะระบบที่เปิดใช้งาน EAP-TLS ได้ เนื่องจากผู้บุกรุกยังคงต้องมีใบรับรองฝั่งไคลเอ็นต์ อันที่จริง ไม่จำเป็นต้องใช้รหัสผ่านด้วยซ้ำ เนื่องจากใช้เพื่อเข้ารหัสใบรับรองฝั่งไคลเอ็นต์สำหรับการจัดเก็บเท่านั้น ความปลอดภัยสูงสุดที่มีอยู่คือเมื่อ "คีย์ส่วนตัว" ของใบรับรองฝั่งไคลเอ็นต์ถูกเก็บไว้ในสมาร์ทการ์ด [ ^{12 ] ทั้งนี้}เนื่องจากไม่มีวิธีใดที่จะขโมยคีย์ส่วนตัวที่เกี่ยวข้องกับใบรับรองฝั่งไคลเอ็นต์จากสมาร์ทการ์ดได้โดยไม่ต้องขโมยการ์ดนั้น การขโมยสมาร์ทการ์ดทางกายภาพมีแนวโน้มที่จะถูกสังเกตเห็น (และสมาร์ทการ์ดจะถูกเพิกถอนทันที) มากกว่าการขโมยรหัสผ่าน (ทั่วไป) ที่จะถูกสังเกตเห็น นอกจากนี้ โดยทั่วไปแล้วรหัสส่วนตัวบนสมาร์ทการ์ดจะถูกเข้ารหัสโดยใช้รหัส PIN ที่มีเพียงเจ้าของสมาร์ทการ์ดเท่านั้นที่รู้ ซึ่งลดประโยชน์ในการขโมยลงอย่างมาก แม้กระทั่งก่อนที่การ์ดจะถูกแจ้งว่าถูกขโมยและถูกยกเลิกก็ตาม

EAP-MD5 เป็นวิธีการ EAP เพียงวิธีเดียวที่ใช้มาตรฐาน IETF Standards Track เมื่อมีการกำหนดครั้งแรกใน RFC ดั้งเดิมสำหรับ EAP คือRFC 2284วิธีการนี้ให้ความปลอดภัยขั้นต่ำฟังก์ชันแฮชMD5มีช่องโหว่ต่อการโจมตีแบบพจนานุกรมและไม่รองรับการสร้างคีย์ ทำให้ไม่เหมาะสำหรับใช้กับ WEP แบบไดนามิก หรือ WPA/WPA2 ระดับองค์กร EAP-MD5 แตกต่างจากวิธีการ EAP อื่นๆ ตรงที่ให้การตรวจสอบความถูกต้องของ EAP peer กับ EAP server เท่านั้น แต่ไม่มีการตรวจสอบความถูกต้องร่วมกัน เนื่องจากไม่ให้การตรวจสอบความถูกต้องของ EAP server วิธีการ EAP นี้จึงมีช่องโหว่ต่อการโจมตีแบบ man-in-the-middle ^{[ 13 ]}การสนับสนุน EAP-MD5 ถูกรวมไว้ครั้งแรกในWindows 2000และถูกยกเลิกในWindows Vista ^{[ 14 ]} 

EAP Protected One-Time Password (EAP-POTP) ซึ่งอธิบายไว้ในRFC 4793เป็นวิธีการ EAP ที่พัฒนาโดย RSA Laboratories ซึ่งใช้โทเค็นรหัสผ่านแบบใช้ครั้งเดียว (OTP) เช่น อุปกรณ์ฮาร์ดแวร์แบบพกพา หรือโมดูลฮาร์ดแวร์หรือซอฟต์แวร์ที่ทำงานบนคอมพิวเตอร์ส่วนบุคคล เพื่อสร้างคีย์การตรวจสอบสิทธิ์ EAP-POTP สามารถใช้เพื่อให้การตรวจสอบสิทธิ์แบบฝ่ายเดียวหรือแบบสองฝ่าย และวัสดุคีย์ในโปรโตคอลที่ใช้ EAP ได้  

วิธีการ EAP-POTP ให้การตรวจสอบสิทธิ์ผู้ใช้แบบสองปัจจัย ซึ่งหมายความว่าผู้ใช้จำเป็นต้องมีการเข้าถึงโทเค็นทางกายภาพและความรู้เกี่ยวกับหมายเลขประจำตัวส่วนบุคคล (PIN) เพื่อทำการตรวจสอบสิทธิ์^{[ 15 ]}

^{[ 1 ]} EAP Pre-shared key (EAP-PSK) ซึ่งกำหนดไว้ในRFC4764เป็นวิธีการ EAP สำหรับการตรวจสอบความถูกต้องร่วมกันและการสร้างคีย์เซสชันโดยใช้คีย์ที่ใช้ร่วมกันล่วงหน้า(PSK) โดยจะให้ช่องทางการสื่อสารที่ได้รับการป้องกันเมื่อการตรวจสอบความถูกต้องร่วมกันสำเร็จ เพื่อให้ทั้งสองฝ่ายสามารถสื่อสารกันได้ และได้รับการออกแบบมาเพื่อการตรวจสอบความถูกต้องบนเครือข่ายที่ไม่ปลอดภัย เช่น IEEE 802.11  

EAP-PSK ได้รับการบันทึกไว้ใน RFC ทดลอง ซึ่งเป็นวิธีการ EAP ที่มีน้ำหนักเบาและขยายได้ โดยไม่จำเป็นต้องใช้การเข้ารหัสแบบกุญแจสาธารณะ การแลกเปลี่ยนโปรโตคอลของวิธีการ EAP จะดำเนินการโดยใช้ข้อความอย่างน้อยสี่ข้อความ

รหัสผ่าน EAP (EAP-PWD) ซึ่งกำหนดไว้ในRFC 5931เป็นวิธีการ EAP ที่ใช้รหัสผ่านร่วมกันสำหรับการตรวจสอบสิทธิ์ รหัสผ่านอาจเป็นรหัสผ่านที่มีเอนโทรปีต่ำและอาจดึงมาจากชุดรหัสผ่านที่เป็นไปได้บางชุด เช่น พจนานุกรม ซึ่งผู้โจมตีสามารถเข้าถึงได้ การแลกเปลี่ยนคีย์พื้นฐานมีความทนทานต่อการโจมตีแบบแอคทีฟ การโจมตีแบบพาสซีฟ และการโจมตีโดยใช้พจนานุกรม  

EAP-PWD อยู่ในพื้นฐานของ Android 4.0 (ICS) อยู่ในเซิร์ฟเวอร์ RADIUS FreeRADIUS ^{[ 16 ]}และ Radiator ^{[ 17 ]}และอยู่ใน hostapd และ wpa_supplicant ^{[ 18 ]}

EAP Tunneled Transport Layer Security (EAP-TTLS) เป็นโปรโตคอล EAP ที่ขยายTLSได้รับการพัฒนาร่วมกันโดยFunk SoftwareและCerticomและได้รับการสนับสนุนอย่างกว้างขวางในหลายแพลตฟอร์ม Microsoft ไม่ได้รวมการสนับสนุนแบบเนทีฟสำหรับโปรโตคอล EAP-TTLS ในWindows XP , Vistaหรือ7การสนับสนุน TTLS บนแพลตฟอร์มเหล่านี้ต้องใช้ซอฟต์แวร์ที่ได้รับการรับรอง Encryption Control Protocol (ECP) จากบริษัทภายนอกMicrosoft Windowsเริ่มให้การสนับสนุน EAP-TTLS ในWindows 8 [ ^{19 ]}การสนับสนุน EAP-TTLS ^{[ 20 ] ปรากฏ} ใน Windows Phone เวอร์ชัน 8.1 ^{[ 21 ]}

ลูกค้าสามารถยืนยันตัวตนผ่านใบรับรอง PKIที่ลงนามโดยCAกับเซิร์ฟเวอร์ได้ แต่ไม่จำเป็นเสมอไป วิธีนี้ช่วยลดความซับซ้อนของขั้นตอนการตั้งค่าอย่างมาก เนื่องจากไม่จำเป็นต้องมีใบรับรองในทุกเครื่องลูกข่าย

หลังจากที่เซิร์ฟเวอร์ได้รับการตรวจสอบสิทธิ์อย่างปลอดภัยกับไคลเอนต์ผ่านใบรับรอง CA ของเซิร์ฟเวอร์ และอาจรวมถึงการตรวจสอบสิทธิ์ของไคลเอนต์กับเซิร์ฟเวอร์ด้วย เซิร์ฟเวอร์จะสามารถใช้การเชื่อมต่อที่ปลอดภัย ("อุโมงค์") ที่สร้างขึ้นเพื่อตรวจสอบสิทธิ์ของไคลเอนต์ได้ โดยสามารถใช้โปรโตคอลและโครงสร้างพื้นฐานการตรวจสอบสิทธิ์ที่มีอยู่และใช้งานกันอย่างแพร่หลาย ซึ่งรวมถึงกลไกการใช้รหัสผ่านและฐานข้อมูลการตรวจสอบสิทธิ์แบบเดิม ในขณะที่อุโมงค์ที่ปลอดภัยจะช่วยป้องกันการดักฟังและการโจมตีแบบคนกลางโปรดทราบว่าชื่อผู้ใช้จะไม่ถูกส่งในรูปแบบข้อความธรรมดาที่ไม่เข้ารหัส ซึ่งช่วยเพิ่มความเป็นส่วนตัว

EAP-TTLS มีสองเวอร์ชันที่แตกต่างกัน ได้แก่ EAP-TTLS ดั้งเดิม (หรือ EAP-TTLSv0) และ EAP-TTLSv1 EAP-TTLSv0 ได้รับการอธิบายไว้ในRFC 5281ส่วน EAP-TTLSv1 นั้นมีให้ใช้งานในรูปแบบร่างของอินเทอร์เน็ต^{[ 22 ]} 

EAP Internet Key Exchange v. 2 (EAP-IKEv2) เป็นวิธีการของ EAP ที่อิงตาม โปรโตคอล Internet Key Exchangeเวอร์ชัน 2 (IKEv2) โดยให้การตรวจสอบความถูกต้องร่วมกันและการสร้างคีย์เซสชันระหว่าง EAP peer และ EAP server รองรับเทคนิคการตรวจสอบความถูกต้องที่อิงตามข้อมูลประจำตัวประเภทต่อไปนี้:

คู่กุญแจที่ไม่สมมาตร

คู่กุญแจสาธารณะ/ส่วนตัว โดยที่กุญแจสาธารณะถูกฝังอยู่ในใบรับรองดิจิทัลและกุญแจส่วนตัว ที่เกี่ยวข้องนั้น มีเพียงฝ่ายเดียวเท่านั้นที่ทราบ

รหัสผ่าน

สตริงบิตที่ มีเอนโทรปีต่ำซึ่งทั้งเซิร์ฟเวอร์และปลายทางทราบได้

กุญแจสมมาตร

สตริงบิตที่มีเอนโทรปีสูง ซึ่งทั้งเซิร์ฟเวอร์และปลายทางทราบข้อมูลนั้น

เป็นไปได้ที่จะใช้ข้อมูลประจำตัวการตรวจ สอบสิทธิ์ที่แตกต่างกัน (และด้วยเหตุนี้จึงใช้เทคนิคที่แตกต่างกัน) ในแต่ละทิศทาง ตัวอย่างเช่น เซิร์ฟเวอร์ EAP ตรวจสอบสิทธิ์ตัวเองโดยใช้คู่คีย์สาธารณะ/ส่วนตัว และฝั่ง EAP ใช้คีย์สมมาตร อย่างไรก็ตาม ไม่ใช่ทุกชุดค่าผสมทางทฤษฎีทั้งเก้าแบบที่คาดว่าจะเกิดขึ้นในทางปฏิบัติ โดยเฉพาะอย่างยิ่ง มาตรฐานRFC 5106ระบุถึงกรณีการใช้งานสี่กรณี ได้แก่ เซิร์ฟเวอร์ตรวจสอบสิทธิ์ด้วยคู่คีย์อสมมาตร ในขณะที่ไคลเอ็นต์ใช้หนึ่งในสามวิธี และทั้งสองฝ่ายใช้คีย์สมมาตร  

EAP-IKEv2 ได้รับการอธิบายไว้ในRFC 5106และ มี การใช้งานต้นแบบอยู่แล้ว  

การตรวจสอบสิทธิ์แบบยืดหยุ่นผ่านอุโมงค์ที่ปลอดภัย (EAP-FAST; RFC 4851 ) เป็นข้อเสนอโปรโตคอลโดยCisco Systems เพื่อ ใช้แทนLEAP ^{[ 23 ]}โปรโตคอลนี้ได้รับการออกแบบมาเพื่อแก้ไขจุดอ่อนของ LEAP ในขณะที่ยังคงรักษาการใช้งานแบบ "น้ำหนักเบา" ไว้ การใช้ใบรับรองเซิร์ฟเวอร์เป็นทางเลือกใน EAP-FAST EAP-FAST ใช้ข้อมูลประจำตัวการเข้าถึงที่ได้รับการป้องกัน (PAC) เพื่อสร้างอุโมงค์ TLS ซึ่งข้อมูลประจำตัวของไคลเอ็นต์จะได้รับการตรวจสอบ  

EAP-FAST มีสามขั้นตอน: ^{[ 24 ]}

เมื่อเปิดใช้งานการจัดเตรียม PAC อัตโนมัติ EAP-FAST จะมีช่องโหว่ที่ผู้โจมตีสามารถดักจับ PAC และใช้ข้อมูลนั้นเพื่อบุกรุกข้อมูลประจำตัวของผู้ใช้ได้ ช่องโหว่นี้สามารถแก้ไขได้โดยการจัดเตรียม PAC ด้วยตนเอง หรือโดยการใช้ใบรับรองเซิร์ฟเวอร์สำหรับขั้นตอนการจัดเตรียม PAC

ควรทราบว่าไฟล์ PAC นั้นออกให้สำหรับผู้ใช้แต่ละราย นี่เป็นข้อกำหนดในRFC 4851มาตรา 7.4.4 ดังนั้นหากผู้ใช้ใหม่ล็อกอินเข้าสู่เครือข่ายจากอุปกรณ์ใด ๆ จะต้องสร้างไฟล์ PAC ใหม่ก่อน นี่เป็นเหตุผลหนึ่งที่ทำให้ยากที่จะใช้งาน EAP-FAST ในโหมดการจัดเตรียมแบบไม่ปลอดภัยสำหรับผู้ใช้ที่ไม่ระบุตัวตน ทางเลือกอื่นคือการใช้รหัสผ่านของอุปกรณ์แทน แต่ในกรณีนั้น อุปกรณ์จะได้รับการตรวจสอบความถูกต้องบนเครือข่าย ไม่ใช่ผู้ใช้  

EAP-FAST สามารถใช้งานได้โดยไม่ต้องใช้ไฟล์ PAC โดยจะเปลี่ยนไปใช้ TLS ปกติแทน

EAP-FAST รองรับโดยธรรมชาติใน Apple OS X 10.4.8 และเวอร์ชันที่ใหม่กว่าCiscoจัดหาโมดูล EAP-FAST ^{[ 25 ]}สำหรับWindows Vista ^{[ 26 ]}และระบบปฏิบัติการเวอร์ชันที่ใหม่กว่า ซึ่งมีสถาปัตยกรรม EAPHost ที่ขยายได้สำหรับวิธีการตรวจสอบสิทธิ์และผู้ร้องขอใหม่^{[ 27 ]}

โปรโตคอลการตรวจสอบสิทธิ์แบบขยายได้ผ่านอุโมงค์ (TEAP; RFC 7170 ) เป็นวิธีการ EAP แบบใช้อุโมงค์ ซึ่งช่วยให้การสื่อสารที่ปลอดภัยระหว่างผู้รับและเซิร์ฟเวอร์เกิดขึ้นได้โดยใช้โปรโตคอล Transport Layer Security (TLS) เพื่อสร้างอุโมงค์ที่มีการตรวจสอบสิทธิ์ร่วมกัน ภายในอุโมงค์นั้น จะใช้ TLV (Type-Length-Value) เพื่อส่งข้อมูลที่เกี่ยวข้องกับการตรวจสอบสิทธิ์ระหว่างผู้รับ EAP และเซิร์ฟเวอร์ EAP  

นอกเหนือจากการตรวจสอบสิทธิ์แบบ Peer-to-Peer แล้ว TEAP ยังอนุญาตให้ Peer ขอใบรับรองจากเซิร์ฟเวอร์โดยการส่งคำขอใน รูปแบบ PKCS#10หลังจากได้รับคำขอใบรับรองและตรวจสอบสิทธิ์ Peer แล้ว เซิร์ฟเวอร์สามารถจัดเตรียมใบรับรองให้กับ Peer ในรูปแบบ PKCS#7 ( RFC 2325 ) ได้ เซิร์ฟเวอร์ยังสามารถแจกจ่ายใบรับรองรากที่เชื่อถือได้ให้กับ Peer ในรูปแบบ PKCS#7 ( RFC 2325 ) ได้อีกด้วย การดำเนินการทั้งสองอย่างนี้ถูกห่อหุ้มไว้ใน TLV ที่เกี่ยวข้องและเกิดขึ้นอย่างปลอดภัยภายในอุโมงค์ TLS ที่สร้างขึ้นแล้ว   

โมดูลระบุตัวตนผู้สมัครใช้บริการ EAP (EAP-SIM) ใช้สำหรับการตรวจสอบสิทธิ์และการแจกจ่ายคีย์เซสชันโดยใช้โมดูลระบุตัวตนผู้สมัครใช้บริการ (SIM) จากระบบสื่อสารเคลื่อนที่ทั่วโลก ( GSM )

เครือข่ายโทรศัพท์มือถือ GSM ใช้การ์ดโมดูลระบุตัวตนผู้สมัครใช้บริการ (SUBSIM) ในการตรวจสอบสิทธิ์ผู้ใช้ EAP-SIM ใช้ขั้นตอนวิธีตรวจสอบสิทธิ์ SIM ระหว่างไคลเอ็นต์และ เซิร์ฟเวอร์ การตรวจสอบสิทธิ์ การอนุญาต และการบัญชี (AAA)เพื่อให้เกิดการตรวจสอบสิทธิ์ร่วมกันระหว่างไคลเอ็นต์และเครือข่าย

ในระบบ EAP-SIM การสื่อสารระหว่างซิมการ์ดและศูนย์ตรวจสอบสิทธิ์ (Authentication Centre หรือ AuC) จะเข้ามาแทนที่ความจำเป็นในการตั้งรหัสผ่านล่วงหน้าระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ AAA

อัลกอริทึม A3/A8 กำลังถูกเรียกใช้งานหลายครั้ง โดยใช้ค่าท้าทาย 128 บิตที่แตกต่างกัน ดังนั้นจะมีค่า Kc-64 บิตมากขึ้น ซึ่งจะถูกนำมาผสมผสานกันเพื่อสร้างกุญแจที่แข็งแกร่งขึ้น (ค่า Kc- จะไม่ถูกนำมาใช้โดยตรง) นอกจากนี้ ปัญหาการขาดการตรวจสอบความถูกต้องร่วมกันในระบบ GSM ก็ได้รับการแก้ไขแล้ว

EAP-SIM ได้รับการอธิบายไว้ใน RFC 4186 

EAP-AKA (Extensible Authentication Protocol Method for Universal Mobile Telecommunications System (UMTS) Authentication and Key Agreement) เป็นกลไก EAP สำหรับการตรวจสอบสิทธิ์และการ แจกจ่าย คีย์เซสชันโดยใช้โมดูลระบุตัวตนผู้สมัครสมาชิก UMTS ( USIM ) EAP-AKA ได้รับการกำหนดไว้ในRFC 4187 

EAP-AKA เป็นรูปแบบหนึ่งของ EAP-AKA ที่กำหนดไว้ในRFC 5448และใช้สำหรับการเข้าถึง เครือข่ายหลัก 3GPP โดยไม่ผ่าน มาตรฐาน 3GPP ตัวอย่างเช่น ผ่านEVDO , WiFiหรือWiMax 

EAP Generic Token Card หรือ EAP-GTC เป็นวิธีการ EAP ที่สร้างขึ้นโดย Cisco เพื่อเป็นทางเลือกแทน PEAPv0/EAP-MSCHAPv2 และกำหนดไว้ในRFC 2284และRFC 3748 EAP-GTC จะส่งคำท้าจากเซิร์ฟเวอร์การตรวจสอบสิทธิ์ และตอบกลับด้วยโทเค็นความปลอดภัยกลไกการตรวจสอบสิทธิ์ PEAP-GTC อนุญาตให้ตรวจสอบสิทธิ์แบบทั่วไปกับฐานข้อมูลหลายแห่ง เช่นNovell Directory Service (NDS) และLightweight Directory Access Protocol (LDAP) รวมถึงการใช้ รหัสผ่านแบบ ใช้ ครั้งเดียว  

EAP ที่ใช้การแลกเปลี่ยนคีย์เข้ารหัสหรือ EAP-EKE เป็นหนึ่งในวิธีการ EAP ไม่กี่วิธีที่ให้การตรวจสอบความถูกต้องร่วมกันอย่างปลอดภัยโดยใช้รหัสผ่านสั้น ๆ และไม่จำเป็นต้องใช้ใบรับรองคีย์สาธารณะเป็นการแลกเปลี่ยนสามรอบ โดยอิงตามDiffie-Hellman ซึ่ง เป็นรูปแบบหนึ่งของโปรโตคอล EKE ที่เป็นที่รู้จักกันดี

EAP-EKE ถูกกำหนดไว้ใน RFC 6124 

การตรวจสอบสิทธิ์นอกแบนด์ที่คล่องตัวสำหรับ EAP ^{[ 28 ]} (EAP-NOOB) เป็นโซลูชันการบูตสแตรปทั่วไปสำหรับอุปกรณ์ที่ไม่มีข้อมูลประจำตัวการตรวจสอบสิทธิ์ที่กำหนดค่าไว้ล่วงหน้าและยังไม่ได้ลงทะเบียนบนเซิร์ฟเวอร์ใดๆ มีประโยชน์อย่างยิ่งสำหรับอุปกรณ์และของเล่น Internet-of-Things (IoT) ที่ไม่มีข้อมูลเกี่ยวกับเจ้าของ เครือข่าย หรือเซิร์ฟเวอร์ การตรวจสอบสิทธิ์สำหรับวิธีการ EAP นี้ขึ้นอยู่กับช่องทางนอกแบนด์ (OOB) ที่ผู้ใช้ช่วยเหลือระหว่างเซิร์ฟเวอร์และคู่ค้า EAP-NOOB รองรับช่องทาง OOB หลายประเภท เช่น รหัส QR แท็ก NFC เสียง ฯลฯ และแตกต่างจากวิธีการ EAP อื่นๆ ความปลอดภัยของโปรโตคอลได้รับการตรวจสอบโดยการสร้างแบบจำลองอย่างเป็นทางการของข้อกำหนดด้วยเครื่องมือProVerifและMCRL2 ^{[ 29 ]}

EAP-NOOB ทำการเข้ารหัสแบบ Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) ผ่านช่องสัญญาณ EAP แบบอินแบนด์ จากนั้นผู้ใช้จะยืนยันการแลกเปลี่ยนนี้โดยการถ่ายโอนข้อความ OOB ผู้ใช้สามารถถ่ายโอนข้อความ OOB จากอุปกรณ์ฝั่งตรงข้ามไปยังเซิร์ฟเวอร์ได้ เช่น เมื่ออุปกรณ์นั้นเป็นสมาร์ททีวีที่สามารถแสดงรหัส QR ได้ หรือผู้ใช้สามารถถ่ายโอนข้อความ OOB จากเซิร์ฟเวอร์ไปยังอุปกรณ์ฝั่งตรงข้ามได้ เช่น เมื่ออุปกรณ์ที่กำลังบูตสแตรปเป็นกล้องที่สามารถอ่านได้เฉพาะรหัส QR เท่านั้น

EAP ไม่ใช่โปรโตคอลสายส่ง แต่เป็นเพียงการกำหนดรูปแบบข้อความเท่านั้น แต่ละโปรโตคอลที่ใช้ EAP จะกำหนดวิธีการห่อหุ้มข้อความ EAP ภายในข้อความของโปรโตคอลนั้น^{[ 30 ] [ 31 ]}

การห่อหุ้ม EAP ผ่านIEEE 802ได้รับการกำหนดไว้ในIEEE 802.1Xและรู้จักกันในชื่อ "EAP over LANs" หรือ EAPOL ^{[ 32 ] [ 33 ] [ 34 ]}เดิมที EAPOL ได้รับการออกแบบมาสำหรับIEEE 802.3 Ethernet ใน 802.1X-2001 แต่ได้รับการปรับปรุงให้เหมาะสมกับเทคโนโลยี LAN อื่นๆ ของ IEEE 802 เช่นIEEE 802.11 wireless และFiber Distributed Data Interface (ANSI X3T9.5/X3T12 ซึ่งนำมาใช้เป็น ISO 9314) ใน 802.1X-2004 ^{[ 35 ]}โปรโตคอล EAPOL ยังได้รับการแก้ไขเพื่อใช้กับIEEE 802.1AE (MACsec) และIEEE 802.1AR (Initial Device Identity, IDevID) ใน 802.1X-2010 ^{[ 36 ]}

เมื่ออุปกรณ์ Network Access Server (NAS) ที่เปิดใช้งาน 802.1X เช่น อุปกรณ์ Wireless Access Point (WAP) ตาม มาตรฐาน IEEE 802.11i-2004 เรียกใช้ EAP วิธีการ EAP ที่ทันสมัยสามารถให้กลไกการตรวจสอบสิทธิ์ที่ปลอดภัยและเจรจาเพื่อสร้างคีย์ส่วนตัวที่ปลอดภัย (Pair-wise Master Key, PMK) ระหว่างไคลเอ็นต์และ NAS ซึ่งสามารถนำไปใช้สำหรับการเข้ารหัสแบบไร้สายโดยใช้การ เข้ารหัส TKIPหรือCCMP (อิงตามAES ) ได้

โปรโตคอลการตรวจสอบสิทธิ์แบบขยายได้ที่ได้ รับ การปกป้อง หรือที่รู้จักกันในชื่อ Protected EAP หรือ PEAP เป็นโปรโตคอลที่ห่อหุ้ม EAP ไว้ภายในอุโมงค์Transport Layer Security (TLS) ที่อาจเข้ารหัสและตรวจสอบสิทธิ์ได้ ^{[ 37 ] [ 38 ] [ 39 ]}จุดประสงค์คือเพื่อแก้ไขข้อบกพร่องใน EAP; EAP สันนิษฐานว่ามีช่องทางการสื่อสารที่ได้รับการปกป้อง เช่น ช่องทางที่จัดหาโดยระบบรักษาความปลอดภัยทางกายภาพ ดังนั้นจึงไม่มีการจัดเตรียมสิ่งอำนวยความสะดวกสำหรับการปกป้องการสนทนา EAP ^{[ 40 ]}

PEAP ได้รับการพัฒนาร่วมกันโดย Cisco Systems, Microsoft และ RSA Security PEAPv0 เป็นเวอร์ชันที่รวมอยู่ในMicrosoft Windows XPและถูกกำหนดไว้ในร่าง draft-kamath-pppext-peapv0-00 PEAPv1 และ PEAPv2 ถูกกำหนดไว้ในเวอร์ชันต่างๆ ของร่าง draft-josefsson-pppext-eap-tls-eap PEAPv1 ถูกกำหนดไว้ในร่าง draft-josefsson-pppext-eap-tls-eap-00ถึงร่าง draft-josefsson-pppext-eap-tls-eap-05 [ ^{41 ]}และ PEAPv2 ถูกกำหนดไว้ในเวอร์ชันที่เริ่มต้นด้วย^ร่าง draft-josefsson-pppext-eap-tls-eap- 06 ^{[ 42 ]}

โปรโตคอลระบุเพียงการเชื่อมโยงกลไก EAP หลายตัวเข้าด้วยกันเท่านั้น ไม่ได้ระบุวิธีการเฉพาะใดๆ^{[ 38 ] [ 43 ]}การใช้ วิธี EAP-MSCHAPv2และEAP-GTCเป็นวิธีที่ได้รับการสนับสนุนมากที่สุด

โปรโตคอล RADIUSและDiameter AAAทั้งสอง โปรโตคอล สามารถห่อหุ้มข้อความ EAP ได้ โดยทั่วไปแล้ว อุปกรณ์ Network Access Server (NAS) จะใช้โปรโตคอลเหล่านี้ในการส่งต่อแพ็กเก็ต EAP ระหว่างปลายทาง IEEE 802.1X และเซิร์ฟเวอร์ AAA เพื่ออำนวยความสะดวกในการใช้งาน IEEE 802.1X

โปรโตคอลสำหรับการส่งข้อมูลการตรวจสอบสิทธิ์เพื่อการเข้าถึงเครือข่าย (PANA) เป็นโปรโตคอลแบบ IP ที่อนุญาตให้อุปกรณ์ตรวจสอบสิทธิ์ตัวเองกับเครือข่ายเพื่อได้รับอนุญาตให้เข้าถึง PANA จะไม่กำหนดโปรโตคอลการตรวจสอบสิทธิ์ใหม่ การแจกจ่ายคีย์ การตกลงคีย์ หรือโปรโตคอลการสร้างคีย์ใดๆ สำหรับวัตถุประสงค์เหล่านี้ จะใช้ EAP และ PANA จะส่งข้อมูล EAP PANA อนุญาตให้เลือกผู้ให้บริการแบบไดนามิก รองรับวิธีการตรวจสอบสิทธิ์ที่หลากหลาย เหมาะสำหรับผู้ใช้ที่โรมมิ่ง และเป็นอิสระจากกลไกของเลเยอร์ลิงก์

EAP เดิมทีเป็นส่วนขยายการตรวจสอบสิทธิ์สำหรับโปรโตคอล Point-to-Point (PPP) PPP รองรับ EAP มาตั้งแต่ EAP ถูกสร้างขึ้นเพื่อเป็นทางเลือกแทนโปรโตคอลChallenge-Handshake Authentication Protocol (CHAP) และโปรโตคอลPassword Authentication Protocol (PAP) ซึ่งในที่สุดก็ถูกรวมเข้ากับ EAP ส่วนขยาย EAP สำหรับ PPP ได้รับการกำหนดไว้ครั้งแรกในRFC 2284ซึ่งปัจจุบันล้าสมัยไปแล้วโดย RFC 3748  

• โปรโตคอลการตรวจสอบสิทธิ์
• การส่งมอบกุญแจ
• ไอทู-ทีX.1035

• "AAA และความปลอดภัยเครือข่ายสำหรับการเข้าถึงผ่านอุปกรณ์เคลื่อนที่: RADIUS, DIAMETER, EAP, PKI และการเคลื่อนที่ของ IP" โดย M Nakhjiri สำนักพิมพ์ John Wiley and Sons, Ltd.

• RFC  3748 : โปรโตคอลการตรวจสอบสิทธิ์แบบขยายได้ (EAP) (มิถุนายน 2547)
• RFC  5247 : กรอบการจัดการคีย์โปรโตคอลการตรวจสอบสิทธิ์แบบขยายได้ (EAP) (สิงหาคม 2551)
• ตั้งค่า RADIUS สำหรับเครือข่ายไร้สาย 802.1x ที่ปลอดภัย
• วิธีการลงนามด้วยตนเองในเซิร์ฟเวอร์ RADIUS สำหรับการตรวจสอบสิทธิ์ PEAP หรือ EAP-TTLS ที่ปลอดภัย
• โปรโตคอลการตรวจสอบสิทธิ์แบบขยายได้บน Microsoft TechNet
• EAPHost ใน Windows Vista และ Windows Server 2008
• ไวร์1x
• "กลุ่มทำงานปรับปรุงวิธีการ IETF EAP (emu)"
• "โปรโตคอลการตรวจสอบสิทธิ์ EAP-POTP"คู่มือการดูแลระบบและการกำหนดค่า Steel Belted Radius Carrier 7.0 Juniper Networks