प्रॉम्प्ट और दायरा
एक एंटरप्राइज़ सेवा चाहती है कि अधिकृत की (authorized-key) वाले क्लाइंट्स चुनिंदा संसाधनों तक पहुंचें, बिना किसी अनऑथेंटिकेटेड क्लाइंट को 401 प्रतिक्रियाओं या चुनौतियों के माध्यम से उनके अस्तित्व की जांच (probe) करने की अनुमति दिए। टीम IETF RFC 9729 पर विचार कर रही है, जो फरवरी 2025 का स्टैंडर्ड्स ट्रैक RFC है। यह स्कीम कनेक्शन-बाउंड सिग्नेचर इनपुट बनाने के लिए TLS कीइंग-मटीरियल एक्सपोर्टर का उपयोग करती है और Authorization: Concealed में प्रमाण भेजती है।
क्लाइंट, एज गेटवे और ओरिजिन डिप्लॉयमेंट को डिज़ाइन करें। 48-बाइट एक्सपोर्टर आउटपुट, ऑथेंटिकेशन पैरामीटर्स, TLS-वर्जन आवश्यकता, कनेक्शन पुनर्चक्रण (reuse), की निरस्तीकरण (revocation), लीगेसी फ़ॉलबैक और रोलआउट परीक्षणों की व्याख्या करें। कार्यान्वयन ऑडिट में सत्यापित 2026 इरेटम (erratum) को शामिल करें।
इंटरव्यूअर क्या मूल्यांकन करता है
इंटरव्यूअर चाहता है कि आप ऑथेंटिकेशन क्षमता को छिपाने और फ्रेशनेस (ताज़गी) की गारंटी देने के बीच अंतर करें: RFC 9729 कोई चुनौती नहीं भेजता है, लेकिन प्रमाण की फ्रेशनेस अंतर्निहित TLS कनेक्शन के लाइफटाइम द्वारा बंधी होती है।
एक मजबूत उत्तर में केवल कुछ हेडर्स के नाम लेने के बजाय Concealed-Auth-Export की सुरक्षित फ़ॉरवर्डिंग, प्रोटोकॉल-विशिष्ट कीज़, HTTP/2 और HTTP/3 मल्टीप्लेक्सिंग आइसोलेशन, रिवोकेशन-कैश कंसिस्टेंसी, फ़ॉलबैक व्यवहार और कॉन्फ़िगरेशन त्रुटियों का डायग्नोसिस शामिल होता है।
पहले पूछे जाने वाले स्पष्टीकरण
- क्लाइंट कीज़ कौन जारी करता है, क्या कीज़ ओरिजिन-विशिष्ट हैं, और क्या शॉर्ट-लिव्ड कीज़ समर्थित हैं?
- क्या गेटवे और ओरिजिन अलग-अलग हैं, और उनके बीच TLS एक्सपोर्टर आउटपुट कैसे पास किया जाता है?
- क्या संसाधन को कनेक्शन-स्तर की फ्रेशनेस की आवश्यकता है या अनुरोध-स्तर की फ्रेशनेस की?
- यदि कोई लीगेसी क्लाइंट केवल TLS 1.2 का समर्थन करता है, तो क्या Extended Master Secret नेगोशिएट किया गया था?
- क्या रिवोकेशन कुछ ही सेकंड में प्रभावी होना चाहिए, या कैश विंडो स्वीकार्य है?
30-सेकंड का उत्तर
“मैं प्रति-ओरिजिन पब्लिक-की डायरेक्टरी बनाए रखूंगा। क्लाइंट TLS कनेक्शन पर RFC 9729 एक्सपोर्टर का उपयोग करता है, निर्धारित संदर्भ पर हस्ताक्षर करता है, और पैरामीटर भेजता है; गेटवे केवल विश्वसनीय एक्सपोर्टर मटीरियल को पार्स और फ़ॉरवर्ड करता है, जबकि ओरिजिन अंतिम ऑथेंटिकेशन और ऑथराइजेशन निर्णय लेता है। TLS 1.3 बाइंडिंग आवश्यकता को पूरा करता है; TLS 1.2 को Extended Master Secret की आवश्यकता होती है अन्यथा अनुरोध को अनऑथेंटिकेटेड माना जाता है। मैं डुअल-रीड, सिंगल-राइट की रोटेशन और शॉर्ट रिवोकेशन कैश का उपयोग करूंगा। क्योंकि प्रमाण कनेक्शन-स्कोप्ड है, अधिक मजबूत फ्रेशनेस के लिए कनेक्शन रिप्लेसमेंट की आवश्यकता होती है। रोलआउट मेट्रिक्स संसाधन के अस्तित्व को प्रकट किए बिना पार्सिंग, वेरिफिकेशन, रिवोकेशन और फ़ॉलबैक को कवर करते हैं।”
चरण-दर-चरण समाधान
की और ओरिजिन डायरेक्टरी बनाएं
प्रत्येक ओरिजिन के लिए, की आईडी को पब्लिक कीज़, एल्गोरिदम, रीअल्म्स (realms), जारी करने के समय और रिवोकेशन स्थिति में मैप करें। एक क्लाइंट प्राइवेट की Concealed ऑथेंटिकेशन के लिए समर्पित होती है और किसी अन्य प्रोटोकॉल में पुन: उपयोग नहीं की जाती है। RFC 9729 एक निश्चित सिग्नेचर प्रीफ़िक्स जोड़ता है, लेकिन डिप्लॉयमेंट अभी भी की सेपरेशन का स्वामी है। की आईडी को उपयोगकर्ता की गोपनीयता को एनकोड नहीं करना चाहिए; ऑडिट लॉग आंतरिक अपरिवर्तनीय पहचानकर्ताओं का उपयोग करते हैं।
कनेक्शन-बाउंड प्रमाण की गणना करें
क्लाइंट एक्सपोर्टर लेबल EXPORTER-HTTP-Concealed-Authentication, निर्दिष्ट संदर्भ और 48-बाइट आउटपुट का उपयोग करता है। पहले 32 बाइट्स सिग्नेचर इनपुट को फीड करते हैं और अंतिम 16 बाइट्स वेरिफिकेशन मटीरियल के रूप में भेजे जाते हैं। संदर्भ में एल्गोरिदम, की आईडी, पब्लिक की, स्कीम, होस्ट, पोर्ट और रीअल्म शामिल हैं। एक बेमेल वेरिफिकेशन विफलता है; एक अनुमेय (permissive) पार्सर को इसे “ठीक” नहीं करना चाहिए।
exported = TLS-Exporter(label, context, 48)
signature_input = exported[0:32] + domain_separation_prefix
verification = exported[32:48]
Authorization: Concealed k=..., a=..., s=..., p=..., v=...गेटवे-ओरिजिन सीमा परिभाषित करें
एक मोनोलिथिक ओरिजिन सीधे TLS एक्सपोर्टर को पढ़ सकता है। अलग होने पर, गेटवे पैरामीटर सिंटैक्स को मान्य करता है और एक विश्वसनीय आंतरिक चैनल पर Concealed-Auth-Export में 48-बाइट एक्सपोर्टर आउटपुट भेजता है। एक सार्वजनिक क्लाइंट उस नाम के साथ एक हेडर बना सकता है (forge), इसलिए गेटवे को बाहरी मान को ओवरराइट या हटा देना चाहिए। ओरिजिन अभी भी लक्षित फ़ील्ड्स, एल्गोरिदम, की आईडी, पब्लिक की और सिग्नेचर की जांच करता है; गेटवे पार्सिंग ऑथराइजेशन नहीं है।
TLS और प्रोटोकॉल बाधाओं को लागू करें
RFC 9729 के लिए TLS 1.3, या Extended Master Secret के साथ TLS 1.2 की आवश्यकता होती है। अन्यथा सर्वर अनुरोध को अनऑथेंटिकेटेड मानता है। HTTP/2 और HTTP/3 बाइंडिंग का उपयोग कर सकते हैं, लेकिन कनेक्शन-स्तर का प्रमाण एक कनेक्शन पर कई अनुरोधों को कवर कर सकता है। क्लाइंट और गेटवे को सुरक्षा संदर्भों को अलग करना चाहिए ताकि एक टेनेंट दूसरे टेनेंट के Authorization हेडर्स को न पढ़ सके।
फ्रेशनेस, पुनर्चक्रण और रिप्ले को संभालें
एक्सपोर्टर की फ्रेशनेस TLS कनेक्शन से अधिक समय तक नहीं चलती है; यह प्रति HTTP अनुरोध एक स्वतंत्र नॉनस (nonce) नहीं है। यदि किसी संसाधन को एक छोटी विंडो की आवश्यकता है, तो एक नए कनेक्शन की आवश्यकता करें, उदाहरण के लिए इसे बंद करके या HTTP/3 GOAWAY भेजकर, और इसे शॉर्ट-लिव्ड की आईडी और सर्वर समय नीति के साथ संयोजित करें। v को कभी भी अनुरोध नॉनस के रूप में न मानें या होस्ट, पोर्ट और रीअल्म की जांच किए बिना सिग्नेचर स्वीकार न करें।
रोटेट, रिवोक और फ़ॉलबैक करें
डुअल-रीड, सिंगल-राइट रोटेशन का उपयोग करें: नई की प्रकाशित करें, अस्थायी रूप से पुरानी की आईडी स्वीकार करें, क्लाइंट्स को माइग्रेट करें, फिर पुरानी की को रिवोक करें। ऑथराइजेशन से पहले रिवोकेशन की जांच की जाती है और कैश TTL और अमान्यकरण (invalidation) स्पष्ट होते हैं। एक लीगेसी क्लाइंट मौजूदा ऑथेंटिकेशन पथ का उपयोग कर सकता है, लेकिन फ़ॉलबैक प्रतिक्रियाएं समान बाहरी आकार रखती हैं ताकि वे यह प्रकट न करें कि कोई संसाधन मौजूद है या नहीं।
विफलताओं का निरीक्षण और निदान करें
ओरिजिन, क्लाइंट संस्करण, प्रोटोकॉल और एल्गोरिदम द्वारा पैरामीटर पार्सिंग विफलताओं, असमर्थित TLS, अज्ञात की आईडी, पब्लिक-की मिसमैच, सिग्नेचर विफलता, रिवोकेशन हिट्स, गेटवे फ़ॉरवर्डिंग त्रुटियों और फ़ॉलबैक दर को विभाजित करें। कभी भी प्राइवेट कीज़, पूर्ण सिग्नेचर या लिंक करने योग्य उपयोगकर्ता कीज़ को लॉग न करें। RFC 9729 सेक्शन 3.3 संदर्भ स्ट्रिंग और सेक्शन 4 पूर्णांक ABNF को प्रभावित करने वाले सत्यापित इरेटम का ऑडिट करें।
सुरक्षित रूप से स्टेज और टेस्ट करें
पहले एक ओरिजिन और एक रिवोकेबल कम-विशेषाधिकार प्राप्त संसाधन को सक्षम करें। TLS 1.3, TLS 1.2 प्लस EMS, HTTP/2, HTTP/3, स्प्लिट गेटवे और कनेक्शन रिप्लेसमेंट का परीक्षण करें। गलत होस्ट, पोर्ट, रीअल्म, एल्गोरिदम, की आईडी, एक्सपोर्टर लंबाई, डुप्लिकेट हेडर्स, बासी रिवोकेशन कैश और क्रॉस-टेनेंट कनेक्शन मामलों को इंजेक्ट करें; प्रत्येक को अनऑथेंटिकेटेड माना जाना चाहिए। रोलबैक पुरानी डायरेक्टरी और ऑडिट रिकॉर्ड को बनाए रखते हुए नई की जारी करने और स्कीम स्वीकृति को रोकता है।
मॉडल उच्च गुणवत्ता वाला उत्तर
“RFC 9729 कनेक्शन-बाउंड, गैर-जांच योग्य (non-probeable) ऑथेंटिकेशन है, न कि प्रति-अनुरोध नॉनस। क्लाइंट एक्सपोर्टर संदर्भ बनाता है, 48 बाइट्स प्राप्त करता है, और एक समर्पित की के साथ हस्ताक्षर करता है। गेटवे सिंटैक्स को मान्य करता है और विश्वसनीय एक्सपोर्टर आउटपुट को फ़ॉरवर्ड करता है; ओरिजिन TLS स्थितियों, लक्षित फ़ील्ड्स, की आईडी, पब्लिक की, सिग्नेचर, रिवोकेशन और ऑथराइजेशन की जांच करता है। TLS 1.3 या TLS 1.2 प्लस EMS आवश्यक है। कीज़ ओरिजिन-स्कोप्ड होती हैं और डुअल रीड के साथ रोटेट की जाती हैं। मजबूत फ्रेशनेस का मतलब कनेक्शन को बदलना है। रोलआउट मेट्रिक्स पार्सिंग, वेरिफिकेशन, रिवोकेशन और फ़ॉलबैक को कवर करते हैं, और रोलबैक संसाधन स्थिति को उजागर किए बिना नए स्कीम उपयोग को रोकता है।”
सामान्य गलतियाँ
- एक्सपोर्टर को प्रति-अनुरोध नॉनस के रूप में मानना → एक लंबे कनेक्शन पर एक प्रमाण का पुन: उपयोग किया जा सकता है → कनेक्शन फ्रेशनेस बताएं और आवश्यकता पड़ने पर कनेक्शन बदलें।
- केवल गेटवे पर वेरिफिकेशन करना → ओरिजिन जाली आंतरिक हेडर पर भरोसा कर सकता है → ओरिजिन संदर्भ और ऑथराइजेशन को सत्यापित करता है।
- EMS के बिना TLS 1.2 स्वीकार करना → एक्सपोर्टर बाइंडिंग अपर्याप्त है → इसे अनऑथेंटिकेटेड मानें।
- प्रोटोकॉल में कीज़ का पुन: उपयोग करना → क्रॉस-प्रोटोकॉल सिग्नेचर भ्रम → स्कीम और ओरिजिन के लिए समर्पित कीज़ रखें।
- रिवोकेशन को बहुत लंबे समय तक कैश करना → एक रिवोक किया गया क्लाइंट एक्सेस बनाए रखता है → TTL, अमान्यकरण और प्राथमिकता को परिभाषित करें।
- फ़ॉलबैक पर भिन्न संसाधन त्रुटियां लौटाना → संसाधन का अस्तित्व देखने योग्य हो जाता है → बाहरी स्थिति को एकसमान रखें और कारण को आंतरिक रूप से लॉग करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: ओरिजिन कोई चुनौती (challenge) क्यों नहीं भेजता है?
एक चुनौती अनऑथेंटिकेटेड क्लाइंट को बताती है कि संसाधन ऑथेंटिकेशन की अपेक्षा करता है, जिससे गैर-जांच योग्य होने का उद्देश्य विफल हो जाता है। RFC 9729 क्लाइंट को कनेक्शन से बंधे TLS एक्सपोर्टर मटीरियल से प्राप्त प्रमाण भेजने की अनुमति देता है।
फॉलो-अप 2: 48 बाइट्स को 32 और 16 में क्यों विभाजित किया जाता है?
स्पेसिफिकेशन पहले 32 बाइट्स पर हस्ताक्षर करता है और अंतिम 16 बाइट्स को वेरिफिकेशन मटीरियल के रूप में भेजता है ताकि सर्वर एक्सपोर्टर आउटपुट की पुष्टि कर सके। कार्यान्वयन को उन सटीक श्रेणियों का उपयोग करना चाहिए, सभी 48 बाइट्स को नॉनस के रूप में नहीं मानना चाहिए।
फॉलो-अप 3: क्या गेटवे से एक्सपोर्टर को फ़ॉरवर्ड करना सुरक्षित है?
केवल एक विश्वसनीय, अखंडता-संरक्षित (integrity-protected) गेटवे-टू-ओरिजिन चैनल पर। एक सार्वजनिक क्लाइंट हेडर नाम को जाली बना सकता है, इसलिए गेटवे को इसे ओवरराइट या हटा देना चाहिए, और ओरिजिन को आंतरिक चैनल को प्रमाणित करना चाहिए और लंबाई को मान्य करना चाहिए।
फॉलो-अप 4: आप किसी मौजूदा कनेक्शन पर रिवोकेशन को कैसे संभालते हैं?
प्रत्येक ऑथराइजेशन निर्णय पर रिवोकेशन की जांच करें, न कि केवल कनेक्शन बनने पर। अधिक मजबूत फ्रेशनेस के लिए, पुरानी की को रिवोक करें, कनेक्शन बंद होने का संकेत दें, और क्लाइंट को एक नई की के साथ फिर से कनेक्ट करने की आवश्यकता करें।