IKEv1 बनाम IKEv2 पूर्व-साझा कुंजी के साथ: प्रमाणीकरण में क्या अलग है

एक ही पूर्व-साझा कुंजी से विन्यस्त दो गेटवे हैंडशेक पूरा करते हैं, और पैकेट रिकॉर्ड तार के पार जाता कोई रहस्य नहीं दिखाता। यही वह हिस्सा है जो लोग याद रखते हैं। दिलचस्प हिस्सा यह है कि हर संस्करण रहस्य के ज्ञात होने का प्रमाण देने के लिए वास्तव में क्या गणना करता है, क्योंकि IKEv1 और IKEv2 वह प्रमाण अलग-अलग इनपुट से बनाते हैं और ऐसा करते हुए अलग-अलग जानकारी उजागर करते हैं। दोनों ट्रेस साथ-साथ पढ़ें और अंतर दिखावटी रहना बंद कर देता है।

प्रमाण को क्या हासिल करना है

Diffie-Hellman दोनों पक्षों को एक साझा मान देता है जिसके सार्वजनिक आधे हिस्से को देखने वाला कोई भी गणना कर सकता है। अपने आप में यह पहचान के बारे में कुछ सिद्ध नहीं करता: कुंजी विनिमय पूरा करने वाला हमलावर आपके गेटवे जैसा ही साझा मान रखता है। प्रमाणीकरण का चरण इस विनिमय को ऐसे रहस्य से बाँधने के लिए है जो केवल इच्छित पक्षों के पास है, और उन पहचानों तथा मापदंडों से भी जिन पर वे सहमत हुए।

यही बंधन वह कारण है कि हैश कुंजी से अधिक कुछ कवर करता है। अगर यह केवल रहस्य कवर करता, तो हमलावर इसे अलग पहचान या प्रस्तावों वाले दूसरे विनिमय में दोबारा चला सकता था।

IKEv1 Main Mode: SKEYID निकालें, फिर प्रमाण दें

Main Mode छह संदेश चलाता है। पहली जोड़ी सुरक्षा संबंध पर बातचीत करती है, दूसरी Diffie-Hellman के सार्वजनिक मान और nonce का आदान-प्रदान करती है, और तीसरी अभी स्थापित एन्क्रिप्शन के अंतर्गत पहचानें तथा प्रमाणीकरण हैश ले जाती है। RFC 2409 संरचना को परिभाषित करता है: पूर्व-साझा कुंजी प्रमाणीकरण में SKEYID रहस्य और दोनों nonce से निकाला जाता है, और बाद की कुंजी सामग्री SKEYID, Diffie-Hellman के साझा मान, कुकीज़ और स्थिरांकों से।

पाँचवें और छठे संदेश में हैश Diffie-Hellman मान, दो कुकीज़, प्रस्ताव और प्रेषक की पहचान पर SKEYID को कुंजी बनाकर गणना किया जाता है। प्राप्तकर्ता इसे अपने विन्यस्त रहस्य से दोबारा गणना करता है। बेमेल विनिमय समाप्त कर देता है, और रहस्य स्वयं कभी पेलोड नहीं होता।

Aggressive Mode वही काम तीन संदेशों में सिकोड़ देता है, यानी पहचानें और प्रमाणीकरण हैश एन्क्रिप्टेड चैनल बनने से पहले ही यात्रा करते हैं। यह अनुमान लगाए जा सकने वाले रहस्य के लिए वास्तविक जोखिम है, और इस प्रश्न से अलग है कि रहस्य भेजा गया या नहीं। IKEv1 को RFC 9395 ने अप्रचलित कर दिया है, इसलिए पुराना ट्रेस नैदानिक अभ्यास है, परिनियोजन का लक्ष्य नहीं।

IKEv2: अलग व्युत्पत्ति और अलग AUTH पेलोड

IKEv2 IKEv1 की कुंजी अनुसूची दोबारा नहीं उपयोग करता। प्रारंभिक IKE कुंजियाँ nonce और Diffie-Hellman के साझा मान से बने बीज से आती हैं, और संतति सुरक्षा संबंध उसी से व्युत्पन्न होते हैं। पूर्व-साझा कुंजी बीज को बिल्कुल नहीं पोषित करती।

फिर प्रमाणीकरण AUTH पेलोड के रूप में दिखाई देता है। साझा कुंजी प्रमाणीकरण के लिए RFC 7296 रहस्य का भरा हुआ रूप निर्धारित करता है, जो रहस्य को स्थिर स्ट्रिंग के साथ हैश करके प्राप्त होता है Key Pad for IKEv2, और फिर हस्ताक्षरित विनिमय डेटा तथा पहचान को उस भरी हुई कुंजी से हैश किया जाता है। सत्यापनकर्ता वही मान दोबारा बना सकता है; देखने वाला रहस्य के बिना नहीं बना सकता।

ध्यान दें क्या बदला। IKEv1 में रहस्य प्रमाणीकरण हैश के अस्तित्व से पहले ही कुंजी अनुसूची में गुँधा जाता है; IKEv2 में कुंजी अनुसूची रहस्य से स्वतंत्र है और प्रमाण हस्ताक्षरित ऑक्टेट से बंधा अलग पेलोड है। वही वैचारिक गारंटी, अलग मशीनरी, और इसीलिए मापदंडों के नाम और रिकॉर्ड एक-से-एक नहीं मिलते।

देखने वाला वास्तव में क्या सीखता है

Diffie-Hellman के सार्वजनिक मान, प्रस्ताव, nonce और कुकीज़ दोनों संस्करणों में दिखाई देते हैं। पहचानें IKEv1 Aggressive Mode में दिखाई देती हैं और बाकी मामलों में सुरक्षित रहती हैं। रहस्य कभी दिखाई नहीं देता।

इस अंतिम वाक्य की एक सीमा है जो बतानी चाहिए। कमज़ोर, मनुष्य द्वारा चुना गया रहस्य अनुमान से हमला किया जा सकता है: हमलावर गणना करता है कि किसी उम्मीदवार रहस्य के लिए प्रमाणीकरण मान क्या होगा और तुलना करता है। IKEv1 Aggressive Mode इसे सबसे सस्ता बनाता है क्योंकि प्रमाण खुले में है, और मानक सामान्य रूप से कम एन्ट्रॉपी वाले रहस्यों के प्रति चेतावनी देते हैं। रहस्य कभी न भेजना बुरे रहस्य को सुरक्षित बनाने के बराबर नहीं है।

इस तुलना का क्या करें

हर पक्ष-जोड़ी के लिए एक अद्वितीय रहस्य प्रयोग करें, उसे यादृच्छिक स्रोत से बनाएँ, और उसी प्रावधान पथ से बदलें जिसने उसे वितरित किया। अगर रहस्य ऐसे कॉन्फ़िगरेशन टेम्पलेट में है जो हर शाखा को भेजा जाता है, तो एक जगह का उल्लंघन हर जगह का उल्लंघन है।

जहाँ परिचालन लागत स्वीकार्य हो वहाँ प्रमाणपत्र-आधारित प्रमाणीकरण को प्राथमिकता दें, क्योंकि यह साझा रहस्य के अनुमान की समस्या हटाता है और हर पक्ष को अलग पहचान देता है। जहाँ पूर्व-साझा कुंजी रहे, उसे लंबा रखें, दायरा संकीर्ण रखें, और IKE संस्करण को अंतर-संचालनीयता का विवरण नहीं बल्कि सुरक्षा निर्णय मानें।