การยืนยันตัวตนแบบไฮบริดของ IKEv1 ย้ายไปสู่การยืนยันตัวตนผู้ใช้ของ IKEv2 อย่างไร
โหมดไฮบริดแยกหลักฐานของเกตเวย์ออกจากหลักฐานของผู้ใช้ การย้ายไป IKEv2 ยังคงการแยกนั้นไว้ แต่เปลี่ยนการแลกเปลี่ยน วิธี EAP และการตรวจสอบใบรับรอง
ทุกโปรไฟล์ VPN แบบเดิมที่ขอใบรับรองเซิร์ฟเวอร์แล้วจึงขอชื่อผู้ใช้ มีเหตุการณ์ยืนยันตัวตนสองครั้งอยู่ในหนึ่งการแลกเปลี่ยน และรูปแบบนี้มีอายุยืนกว่าพร็อตอคอลที่นำมันมา โหมดไฮบริดของ IKEv1 ถูกสร้างขึ้นเพื่อสิ่งนี้โดยเฉพาะ เกตเวย์พิสูจน์ตัวเองด้วยกุญแจสาธารณะ ส่วนผู้ใช้พิสูจน์ตัวเองในภายหลังผ่าน XAuth IKEv2 แสดงแนวคิดสองขั้นเดียวกันด้วยกลไกอื่น และความต่างเหล่านี้คือจุดที่การย้ายระบบล้มเหลว ไม่มีหมายเลขเวอร์ชันใดแปลงสิ่งหนึ่งเป็นอีกสิ่งหนึ่ง และการคัดลอกชื่อตัวเลือกเก่าไปยังโปรไฟล์ใหม่จะได้ไคลเอนต์ที่เจรจาแล้วไม่ยืนยันตัวตนใดเลย
โหมดไฮบริดทำอะไรภายใน IKEv1
ในโปรไฟล์ไฮบริด ฝ่ายตอบสนองลงนามในการแลกเปลี่ยนระยะแรกด้วยใบรับรองของตน ขณะที่ฝ่ายเริ่มต้นจงใจไม่แสดงใบรับรองใดเลย หลักฐานตัวตนจึงไม่สมมาตร และนั่นคือสิ่งที่ทำให้เกตเวย์เก็บ PKI เดิมไว้ได้ ขณะที่ผู้ใช้เก็บรหัสผ่านไดเรกทอรีของตนไว้ เมื่อระยะแรกเสร็จสิ้น XAuth ทำงานเป็นการร้องขอและการตอบกลับที่บรรทุกแอตทริบิวต์ชื่อผู้ใช้และรหัสผ่านภายในช่อง ISAKMP ที่เข้ารหัสแล้ว
สังเกตว่าความเชื่อมั่นไปตกอยู่ที่ใด ใบรับรองตอบว่าไคลเอนต์ไปถึงเกตเวย์ใด ส่วน XAuth ตอบว่าผู้ใช้คนใดต้องการเข้าถึง ทั้งสองอย่างแทนกันไม่ได้ และไคลเอนต์ที่ตั้งไว้ให้ยอมรับใบรับรองเซิร์ฟเวอร์ใดก็ได้ได้ทิ้งคำตอบแรกไปอย่างเงียบ ๆ ป้ายไฮบริดยังถูกใช้กับโหมดก้าวร้าวที่ใช้กุญแจร่วมกันล่วงหน้าร่วมกับ XAuth ซึ่งเป็นการจัดวางอีกแบบที่ประสบการณ์ผู้ใช้เหมือนกัน ดังนั้นจงอ่านโปรไฟล์ไม่ใช่ชื่อ ทั้งสองแบบมาจากร่างที่ไม่มีวันเป็นมาตรฐาน จึงเป็นเหตุให้ผู้ผลิตสองรายทำโหมดไฮบริดได้แต่ทำงานร่วมกับใครไม่ได้
IKEv2 ไปถึงหลักฐานสองอย่างเดียวกันได้อย่างไร
IKEv2 แบ่งงานระหว่าง IKE_SA_INIT กับ IKE_AUTH การแลกเปลี่ยนแรกตกลงข้อเสนอและกุญแจโดยไม่มีตัวตนใดเลย ส่วนที่สองบรรทุก IDi IDr และเพย์โหลด AUTH ภายใต้ EAP เพย์โหลด AUTH แรกของฝ่ายเริ่มต้นออกไปว่างเปล่า ฝ่ายตอบสนองยืนยันตัวตนก่อนด้วยใบรับรองและลายเซ็น จากนั้นบทสนทนา EAP จึงดำเนินไปภายในข้อความ IKE_AUTH
กลไกที่ทำให้ปลอดภัยคือวัสดุกุญแจ วิธี EAP ที่สำเร็จจะส่งออกกุญแจเซสชัน และเพย์โหลด AUTH สุดท้ายของฝ่ายเริ่มต้นคำนวณจากกุญแจนั้น หลักฐานของผู้ใช้จึงผูกกับกุญแจของอุโมงค์ XAuth ไม่มีสิ่งที่เทียบเท่า แอตทริบิวต์ของมันมาถึงหลังระยะแรกและไม่ได้เพิ่มอะไรให้กุญแจ ช่องว่างนี้คือสิ่งที่กรอบ IKEv2 ถูกออกแบบมาเพื่อปิด และนั่นคือเหตุผลที่การเข้าสู่ระบบ IKEv2 ที่ทำงานได้ตรวจสอบใบรับรองเซิร์ฟเวอร์ก่อนจะถามสิ่งใด
ลำดับนี้ยังเป็นการวินิจฉัยที่มีประโยชน์ เมื่อไคลเอนต์บ่นเรื่องข้อมูลรับรองก่อนที่จะแสดงใบรับรองให้คุณเห็น มันไม่ได้ทำการแลกเปลี่ยน EAP ของ IKEv2 เลย
แยกตัวตนสามอย่างออกจากกัน
การย้ายระบบผิดพลาดเมื่อตัวตนสามอย่างรวมลงในช่องเดียว มีตัวตนของเกตเวย์ที่ไคลเอนต์ตรวจสอบ ปกติเป็นชื่อ DNS ใน subject หรือ SAN ของใบรับรอง มีตัวตนของผู้ใช้ที่นำเสนอใน EAP อาจเป็นบัญชีโดเมน ที่อยู่ หรือสตริงตัวตน EAP ที่ชัดเจน และมีแหล่งอนุญาตที่แมปผู้ใช้คนนั้นไปยังเครือข่ายและเส้นทาง
ไวยากรณ์ swanctl ของ strongSwan ทำให้การแยกเห็นได้ชัด การเชื่อมต่อตั้ง remote { auth = pubkey } สำหรับเกตเวย์และ local { auth = eap-mschapv2 } สำหรับผู้ใช้ โดยตัวตน EAP ถูกบรรทุกแยกต่างหาก
เมื่อตัวตนผู้ใช้ในโปรไฟล์ใหม่ต่างจากแอตทริบิวต์ XAuth เดิม เช่นใช้ UPN แทนชื่อสั้น เซิร์ฟเวอร์ยืนยันตัวตนเห็นผู้ใช้ที่ไม่รู้จักและความล้มเหลวดูเหมือนรหัสผ่านผิด ตรวจสอบสตริงตัวตนก่อนตรวจสอบข้อมูลรับรอง
แมปตัวเลือกแล้วจึงคาดหวังกับดัก
การแมปนั้นสั้น และทุกแถวมีกับดักที่ปรากฏเฉพาะตอนยืนยันตัวตน
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
ไม่มีแถวใดเป็นการเปลี่ยนชื่อเฉย ๆ เพย์โหลดการตั้งค่าส่งที่อยู่และตัวแก้ไขผ่านรายการแอตทริบิวต์ที่มีชนิด ขณะที่พื้นที่แอตทริบิวต์ของ XAuth เป็นการประดิษฐ์ของมันเอง การถือว่าทั้งสองใช้แทนกันได้คือหนทางที่โปรไฟล์จะไปขอการตั้งค่าที่เกตเวย์ไม่ส่งมาเลย
ตัวเลือกการรับส่งสมควรมีคำเตือนของตัวเอง IKEv1 แสดงการรับส่งที่น่าสนใจผ่าน proxy ID ที่ผูกกับการแลกเปลี่ยน quick mode ขณะที่ IKEv2 เจรจาตัวเลือกระหว่าง IKE_AUTH และฝ่ายตอบสนองอาจทำให้แคบลง ความไม่ตรงกันทำให้เกิด IKE SA ที่ตั้งขึ้นแล้วแต่ไม่มี child SA ซึ่งไคลเอนต์บางตัวแสดงอย่างมีความสุขว่าเชื่อมต่อแล้ว
มองการเชื่อมต่อเก่าเป็นเส้นเขต
RFC 9395 ประกาศว่า IKEv1 ล้าสมัย การเชื่อมต่อไฮบริดแบบเดิมจึงเป็นเส้นเขตความเข้ากันได้ที่มีวันที่ ไม่ใช่รากฐาน จงรันทั้งสองโปรไฟล์เคียงกันระหว่างการเปลี่ยนแปลง เพราะการทดสอบที่สำคัญไม่ใช่ว่าโปรไฟล์ใหม่ขึ้นมาหรือไม่ แต่คือผู้ใช้คนเดียวกันบนอุปกรณ์เดียวกันเข้าถึงทรัพยากรเดียวกันได้หรือไม่
รักษาการตรวจสอบใบรับรองให้เข้มงวดตลอดทาง เมื่อไคลเอนต์เลิกแสดงใบรับรองของตัวเอง สิ่งล่อใจคือผ่อนการตรวจสอบเซิร์ฟเวอร์จนกว่า handshake จะเสร็จ และนั่นแลกหลักฐานเดียวที่เหลืออยู่กับไอคอนสีเขียว
จดสี่อย่างก่อนปลดระวางโปรไฟล์เก่า วิธี EAP สตริงตัวตน แหล่งอนุญาต และวันที่สิ้นสุดการสนับสนุน