โปรโตคอลการตรวจสอบสิทธิ์แบบขยายได้ ( 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 ได้อีกด้วย 

The Lightweight Extensible Authentication Protocol (LEAP) method was developed by Cisco Systems prior to the IEEE ratification of the 802.11i security standard.^[3] Cisco distributed the protocol through the CCX (Cisco Certified Extensions) as part of getting 802.1X and dynamic WEP adoption into the industry in the absence of a standard. There is no native support for LEAP in any Windows operating system, but it is widely supported by third-party client software most commonly included with WLAN (wireless LAN) devices. LEAP support for Microsoft Windows 7 and Microsoft Windows Vista can be added by downloading a client add in from Cisco that provides support for both LEAP and EAP-FAST. Due to the wide adoption of LEAP in the networking industry many other WLAN vendors claim support for LEAP.

LEAP uses a modified version of MS-CHAP, an authentication protocol in which user credentials are not strongly protected and easily compromised; an exploit tool called ASLEAP was released in early 2004 by Joshua Wright.^[4] Cisco recommends that customers who absolutely must use LEAP do so only with sufficiently complex passwords, though complex passwords are difficult to administer and enforce. Cisco's current recommendation is to use newer and stronger EAP protocols such as EAP-FAST, PEAP, or EAP-TLS.

EAP Transport Layer Security (EAP-TLS), defined in RFC 5216, is an IETF open standard that uses the Transport Layer Security (TLS) protocol, and is well-supported among wireless vendors. EAP-TLS is the original, standard wireless LAN EAP authentication protocol.

EAP-TLS is still considered one of the most secure EAP standards available, although TLS provides strong security only as long as the user understands potential warnings about false credentials, and is universally supported by all manufacturers of wireless LAN hardware and software. Until April 2005, EAP-TLS was the only EAP type vendors needed to certify for a WPA or WPA2 logo.^[5] There are client and server implementations of EAP-TLS in 3Com, Apple, Avaya, Brocade Communications, Cisco, Enterasys Networks, Fortinet, Foundry, Hirschmann, HP, Juniper, Microsoft, and open source operating systems. EAP-TLS is natively supported in Mac OS X 10.3 and above, wpa_supplicant, Windows 2000 SP4, Windows XP and above, Windows Mobile 2003 and above, Windows CE 4.2, and Apple's iOS mobile operating system.

แตกต่างจากการใช้งาน 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