🔐 RADIUS EAP עם IKEv2: להבין את EAP-GTC ואת EAP-MSCHAPv2
ב־VPN לגישה מרחוק, ארכיטקטורה אפשרית משלבת RADIUS , EAP (פרוטוקול אימות ניתן להרחבה) ו־ IKEv2 בתפקידים נפרדים של תעבורה, אימות ו־AAA. ב־Wi-Fi ארגוני, EAP מועבר בדרך כלל ב־802.1X ולא ב־IKEv2. שתי שיטות שכדאי להשוות הן EAP-GTC ו־ EAP-MSCHAPv2 . ההבנה כיצד כל אחת פועלת ומתי להשתמש בה חיונית לאדריכלי רשתות, למהנדסי אבטחה ולמנהלי מערכות.
(מבקש אימות)
(הודעות IKE מוצפנות)
(מאמת)
שרת
(המימוש האחורי תלוי בשיטה)
📡 מהו RADIUS?
RADIUS, ראשי תיבות של Remote Authentication Dial-In User Service ומוגדר ב־RFC 2865/2866, הוא פרוטוקול לקוח־שרת המספק שירותי אימות, הרשאה וחשבונאות שימוש (AAA) . ב־VPN מסוג IKEv2, שרת הגישה לרשת NAS — בדרך כלל שער VPN — פועל כלקוח RADIUS. הוא מעביר נתוני אימות ממשתמש הקצה לשרת RADIUS, כגון Cisco ISE, FreeRADIUS או Microsoft NPS, אשר מאמת את פרטי הגישה מול מאגר זהויות אחורי.
תגובת EAP או התחלת EAP בהתאם לתצורה
EAP-Request
EAP-Response
תוצאת EAP ומאפייני מדיניות
🔑 מהו EAP?
EAP, המוגדר ב־RFC 3748, הוא מסגרת לאימות ולא מנגנון אימות מסוים. הוא מגדיר סוגי הודעות — Request, Response, Success ו־Failure — ומאפשר לשלב שיטות כגון EAP-TLS, EAP-TTLS, PEAP, EAP-GTC ו־EAP-MSCHAPv2. IKEv2 נושא EAP בחילופי IKE_AUTH מוצפנים, לאחר IKE_SA_INIT אך לפני השלמת האימות. הצפנה בשלב הזה אינה תחליף לאימות זהות השער. מקור: RFC 3748: EAP and GTC; RFC 7296: IKEv2 §§2.15–2.16;
🛡️ מהו IKEv2?
IKEv2 מקים ומתחזק שיוכי אבטחה של IPsec. תמיכה ב־EAP היא חלק מפרוטוקול הבסיס המתואר ב־RFC 7296; RFC 5998 הוא הרחבה נפרדת לאימות EAP בלבד, לשיטות מתאימות המספקות אימות הדדי ויצירת מפתחות. זרימת EAP הבסיסית להלן משתמשת באימות השער במפתח ציבורי. יש לבדוק תמיכה בכל מוצר ולקוח, ולא להניח שהיא כללית. מקור: RFC 5998: EAP-only extension;
⚡ EAP-GTC — כרטיס אסימון כללי — RFC 3748
מהו EAP-GTC?
EAP-GTC הוא שיטת אתגר־תגובה טקסטואלית פשוטה המוגדרת ב־RFC 3748. היא יכולה לשאת פלט אסימון או תגובה אחרת שהמשתמש הזין; השיטה עצמה אינה מצפינה את התגובה ואינה גוזרת מפתחות הפעלה. דפוס פריסה נתמך אחד הוא GTC בתוך מנהרת PEAP, המכונה לעיתים PEAP-GTC . מקור: RFC 3748: EAP and GTC;
"הזינו סיסמה:" — טקסט ההנחיה
סיסמה / OTP בטקסט גלוי
(RADIUS Access-Accept)
📋 שדות חבילת GTC להמחשה — אסימון לדוגמה, לא פרטי גישה אמיתיים
EAP-Request (GTC):
+--------+--------+--------+--------+-------------------------+
| Code | Ident | Length | Type | Message (text) |
| 0x01 | 0xXX | 0xXXXX | 0x06 | "Enter OTP:" |
+--------+--------+--------+--------+-------------------------+
EAP-Response (GTC):
+--------+--------+--------+--------+-------------------------+
| Code | Ident | Length | Type | Value (token) |
| 0x02 | 0xXX | 0xXXXX | 0x06 | "847291" |
+--------+--------+--------+--------+-------------------------+
EAP Type 6 = GTC
✅ מתי והיכן משתמשים ב־EAP-GTC
- אימות באמצעות OTP / אסימונים: מערכת אחורית יכולה לאמת תגובות RSA SecurID, TOTP או אסימונים אחרים כאשר השילוב והנחיית הלקוח נתמכים. GTC אינו מממש בעצמו את אלגוריתם האסימון, אינו אוכף שימוש חד־פעמי ואינו הופך OTP לעמיד לדיוג. מקור: NIST SP 800-63B-4: phishing resistance;
- PEAP-GTC בתשתית Cisco: PEAP-GTC הוא אפשרות תאימות במימושים התומכים בשיטה הפנימית הזאת; הוא אינו ברירת מחדל כללית של Cisco. המערכת האחורית יכולה לאמת סיסמה או אסימון שנמסרו בלי לחשב תגובת MSCHAPv2, בכפוף ליכולותיה בפועל.
- לקוחות שאינם Windows: התמיכה תלויה במבקש האימות, בגרסת מערכת ההפעלה, בפרופיל EAP ובמערכת האחורית — לא רק במשפחת מערכת ההפעלה. אימות סיסמה ב־LDAP ואימות אתגר־תגובה מול AD הם נתיבי שילוב שונים.
- IKEv2 עם EAP-GTC: strongSwan מתעד תוסף eap-gtc ל־IKEv2. GTC אינו יוצר MSK: RFC 7296 ממליץ שלא להשתמש בשיטות EAP שאינן יוצרות מפתחות ומגדיר עבורן SK_pi/SK_pr לחישובי AUTH הסופיים. יש לבדוק תמיכה במימוש ולאמת את השרת; זה אינו מודל EAP בלבד של RFC 5998. מקור: strongSwan eap-gtc; RFC 7296: IKEv2 §§2.15–2.16;
PEAP-GTC
NAS / מאמת
FreeRADIUS
LDAP
🔐 EAP-MSCHAPv2 — עיטוף EAP של Microsoft עבור RFC 2759
מהו EAP-MSCHAPv2?
EAP-MSCHAPv2 הוא העיטוף של Microsoft לפרוטוקול MS-CHAPv2, Microsoft Challenge Handshake Authentication Protocol v2, במסגרת EAP. בניגוד ל־EAP-GTC, הוא משתמש ב־ מנגנון אתגר־תגובה הדדי המוכיח החזקה במידע הנגזר מהסיסמה בלי לשלוח אותה עצמה. חילופים שנלכדו עדיין יכולים לאפשר תקיפות לא מקוונות, ולכן הדבר אינו תחליף לאימות תעודת שרת ולערוץ מוגן. Windows תומך בשיטה בפרופילים מתועדים, אך ההתנהגות תלויה בגרסה, במדיניות וב־Credential Guard; אין להשבית הגנת פלטפורמה רק כדי לשמר SSO ישן. מקור: Microsoft: Credential Guard considerations; Microsoft: VPN authentication;
שם משתמש
OpCode=1 — אתגר: אתגר שרת באורך 16 בתים (SC)
OpCode=2: כולל PeerChallenge באורך 16 בתים ו־NT-Response באורך 24 בתים; שדות נוספים הושמטו בתרשים
OpCode=3 — הצלחה: מחרוזת AuthenticatorResponse
אישור OpCode=3 רק אחרי שהלקוח מאמת את AuthenticatorResponse מקור: Microsoft: EAP-MSCHAPv2 syntax;
🧮 מתווה קריפטוגרפי של MSCHAPv2 — הסבר, לא מימוש
סימון הסברי, לא קוד קריפטוגרפי שניתן להרצה.
הסימן || מציין שרשור בתים. UserName אינו כולל שם תחום מקדים.
Challenge = SHA1(PeerChallenge || AuthenticatorChallenge || UserName)[0:8]
PasswordHash = MD4(UTF16LE(Password))
PasswordHashHash = MD4(PasswordHash)
PaddedHash = PasswordHash המרופד באפסים לאורך 21 בתים
K1, K2, K3 = שלושת מקטעי 7 הבתים, המומרים למפתחות DES עם סיביות זוגיות
NTResponse = DES(K1, Challenge) || DES(K2, Challenge) || DES(K3, Challenge)
Digest1 = SHA1(PasswordHashHash || NTResponse || Magic1)
Digest2 = SHA1(Digest1 || Challenge || Magic2)
AuthenticatorResponse = "S=" || uppercase_hex(Digest2)
Magic1 ו־Magic2 הם קבועי בתים שונים המוגדרים בסעיף 8.7 של RFC 2759.
המבנה הוותיק הזה אינו המלצה לתכנון קריפטוגרפיה חדשה.
מקורות למתווה: RFC 2759: MS-CHAPv2; Microsoft: EAP-MSCHAPv2 syntax;
✅ מתי והיכן משתמשים ב־EAP-MSCHAPv2
- PEAP-MSCHAPv2 ברשת Wi-Fi מסוג 802.1X: פרופיל ותיק נפוץ ב־Wi-Fi ארגוני עוטף EAP-MSCHAPv2 ב־PEAP. יש לאכוף שם שרת TLS ורשות אישורים מהימנה; הסתמכות על אישור כל תעודה בידי המשתמש מבטלת את ההגנה.
- VPN מסוג IKEv2 + EAP-MSCHAPv2: Microsoft מתעדת EAP-MSCHAPv2 לאימות ב־VPN המובנה שלה. שער IKEv2 יכול לטפל בשיטה מקומית או להעביר EAP ל־RADIUS; האפשרות השנייה היא בחירת תצורה מפורשת. ל־Always On VPN יש כמה תכנוני אימות, ולכן יש לבדוק את הפרופיל והמדיניות בפועל. מקור: Microsoft: VPN authentication;
- שילוב עם Active Directory: המאמת זקוק למידע מתאים הנגזר מהסיסמה או לשירות שיכול לאמת את תגובת האתגר. שילוב AD יכול להעביר את האימות לבקר תחום, למשל באמצעות Samba/winbind ב־FreeRADIUS. זו אינה קריאת LDAP כללית של גיבובי NT מ־AD, ולא החלפה של MSCHAPv2 ב־Kerberos. מקור: FreeRADIUS: AD integration (4.0 documentation);
- PPP/SSTP ותיקים: MSCHAPv2 הוגדר עבור PPP ומופיע בתכנוני אימות VPN ותיקים. ההיסטוריה הזאת אינה המלצה לפרוס PPTP או להתייחס לכל התעבורות המבוססות על PPP כשוות.
IKEv2/EAP
(NAS / לקוח RADIUS)
שרת RADIUS
אימות באמצעות בקר תחום
⚖️ EAP-GTC מול EAP-MSCHAPv2 — השוואה זו לצד זו
| מאפיין | EAP-GTC | EAP-MSCHAPv2 |
|---|---|---|
| RFC / תקן | RFC 3748 — סוג 6 | EAP של Microsoft; RFC 2759; RFC 3079 למפתחות |
| העברת סיסמה | טקסט גלוי (נדרשת הגנה מאומתת) | אתגר־תגובה עם גיבוב NT |
| אימות הדדי | לא, לא באמצעות GTC לבדו | כן (הוכחה הנגזרת מסיסמה; עדיין לאמת שרת) |
| תמיכה ב־OTP / אסימון | נושא תגובת אסימון של מערכת אחורית נתמכת | אינו תעבורת OTP כללית מובנית |
| Active Directory | תלוי במערכת האחורית (למשל אימות סיסמה נתמך) | נדרש שילוב עם המערכת האחורית (אימות אתגר־תגובה) |
| תמיכה מובנית ב־Windows | יש לבדוק את הלקוח הנבחר (לעיתים נדרש מבקש אימות אחר) | מתועד בפרופילי Windows (תלוי גרסה ומדיניות) |
| מורכבות | פשוטה (אתגר־תגובה בסיסי; סבבים חיצוניים משתנים) | בינונית (חילופי זהות, אתגר והצלחה) |
| שימוש ב־EAP עם IKEv2 | תלוי מימוש; ללא MSK של EAP | פרופילים נתמכים; יש לבדוק מדיניות |
| שיטה פנימית ב־PEAP | PEAP-GTC כאשר נתמך | PEAP-MSCHAPv2 כאשר מוגדר |
| אבטחה ללא מנהרה | ❌ לא בטוח | ⚠️ פגיע לתקיפה לא מקוונת |
🚨 שיקולי אבטחה
| נתיב תקיפה | סיכון EAP-GTC | סיכון EAP-MSCHAPv2 | צמצום הסיכון |
|---|---|---|---|
| האזנה לפרטי גישה | התגובה גלויה בלי ערוץ מוגן | הסיסמה אינה נשלחת, אך תגובה שנלכדה רגישה | לאמת שרת ולהגן על הנתיב המלא |
| נקודת גישה מתחזה / אדם־בתווך | אפשר להעביר הלאה סוד או OTP | לכידת אתגר־תגובה מאפשרת תקיפות | לאמת בקפדנות את תעודת השרת |
| תקיפת מילון לא מקוונת | תלוי בסוג התגובה; GTC עשוי לשאת סיסמה | חולשה מוכרת של המבנה הוותיק | להעדיף תכנון מבוסס תעודות נתמך; להגן על חילופים ותיקים |
| תקיפת שידור חוזר | תלוי בבדיקות חד־פעמיות ועדכניות במערכת האחורית | אתגרים טריים מסייעים; המימוש עדיין חשוב | לאכוף בדיקות שימוש חוזר באסימון ואתגרים טריים; עדיין ניתן לדוג OTP |
⚙️ בדיקת תצורה, לא הוראות פריסה
strongSwan: להבחין בין EAP מקומי למתווך RADIUS
רשימת בדיקה של strongSwan שאינה ניתנת להרצה
- החליטו אם EAP מאומת מקומית או מועבר ל־RADIUS.
- ההגדרה המקורית rightauth=eap-mschapv2 בוחרת שיטת EAP מקומית;
היא אינה מגדירה לבדה מערכת RADIUS אחורית.
- התוסף eap-radius מספק העברה כאשר הוא מוגדר במפורש.
- בדקו את הגרסה המותקנת ואת תיעוד swanctl.conf והתוספים שלה.
- אמתו אמון בתעודת השער ואת הזהות הצפויה בכל לקוח.
- בדקו אלגוריתמים מותרים, הקצאת כתובות ללקוח, בוררי תעבורה,
ניתוב, מדיניות, ביטול תעודות ונתיב AAA המוגן בנפרד.
- בדקו טיפול בסודות בלי לשלב פרטי גישה בדוגמאות.
- בדקו תאימות ומקרי כשל במעבדה מבודדת ומורשית.
כאן לא מיושמת תצורה ולא ניגשים לפרטי גישה.
מקורות למתווה: strongSwan eap-radius;
FreeRADIUS: בדיקת EAP ומערכת אחורית לפי גרסה
רשימת בדיקה של FreeRADIUS שאינה ניתנת להרצה
- זהו את גרסת השרת בפועל; סכמות התצורה שונות בין גרסאות.
- בחרו שיטת EAP, וכאשר נדרש גם שיטה חיצונית מוגנת.
- עבור MSCHAPv2, זהו את המאמת הנתמך לתגובת האתגר.
- עבור GTC, זהו את מערכת אימות הסיסמה או OTP בפועל.
- PAM ומודול OTP אינם בני החלפה רק משום שהערה בקובץ אומרת כך.
- הגדירו זהות שרת, אמון, מדיניות גישה והגנה על תעבורת AAA.
- בדקו שימוש חוזר באסימון, סיסמה שגויה, זהות שרת שגויה וכשל במערכת האחורית.
- הרחיקו סודות מיומנים ומחומרי ביקורת.
זה אינו קובץ eap.conf שניתן לפריסה והוא לא הורץ.
מקורות למתווה: FreeRADIUS: AD integration (4.0 documentation);
🏁 סיכום
גם EAP-GTC וגם EAP-MSCHAPv2 פותרים בעיות שילוב שונות. GTC נושא תגובה טקסטואלית ומסתמך על ערוץ מוגן ומאומת ועל בדיקות אסימון או סיסמה במערכת האחורית; OTP אינו עמיד לדיוג מעצם טבעו. MSCHAPv2 מספק אתגר־תגובה ותיק הנגזר מסיסמה, לא חסינות מודרנית מפני תקיפה לא מקוונת. יש להתאים במפורש שיטת EAP, תעבורה, לקוח, שירות AAA ומערכת זהויות. בתכנון חדש ונתמך, בחנו EAP-TLS עם ניהול תקין של מחזור חיי התעודות והמפתחות הפרטיים. שם של שיטה לבדו אינו מבטיח פריסה מאובטחת. מקור: Microsoft: Credential Guard considerations;
✔ תמיכת לקוח שנבדקה
✔ מערכת אחורית תואמת לסיסמה או אסימון
✔ פרופיל PEAP או IKEv2 נתמך
✔ מדיניות IKEv2/Windows שנבדקה
✔ פרופיל 802.1X ותיק ומוגן
✔ תוכנית מעבר משימוש בסיסמה ותיקה
✔ מבוסס תעודות
✔ להגן על מפתחות; סיסמאות אינן הסיכון היחיד
✔ לבדוק תמיכה ומחזור חיי תעודות