الخلاصة

  • اعتبرت RFC 3983 قناة BEEP جاهزة بعد قبول ملف IRIS وإنشاء القناة، لكن ذلك أثبت قدرة تبادل الرسائل للأنواع المعلنة فقط، ولم يثبت هوية الخادم أو المستخدم.
  • أمكن لنوع السجل اختيار طريقة خاصة لمصادقة الخادم أو الطريقة الأساسية عبر TLS أو إعلان غياب المصادقة. وظل التشفير وهوية المستخدم وإذن الاستعلام والثقة في وجهة الإحالة أدلة مستقلة.

تصل إحالة إلى العميل فتقوده إلى خادم ثان. يستطيع إنشاء قناة مشفرة معه، لكن هل يرسل إليه كلمة المرور نفسها؟ وضعت RFC 3983 هذه المسافة بين الوصول والثقة في صلب التصميم. فالإحالات جزء طبيعي من IRIS، أما تسليم بيانات الاعتماد فقرار جديد عند كل وجهة.

توثق صفحة الحالة والتصويبات وسجل Datatracker مواصفة Standards Track الصادرة في يناير/كانون الثاني 2005. وقد ربطت Internet Registry Information Service ببروتوكول BEEP. ولا تثبت هذه السجلات انتشاراً أو خدمة حية.

اختير BEEP لأنه يوفر مسبقاً التأطير والمصادقة وإدارة الاتصال والتفاوض، مع أدوات وخبرة يمكن إعادة استخدامها. أما إنشاء نقل خاص بـ IRIS فكان سيعيد بناء وظائف مماثلة. ورأى المؤلفون أن HTTP قد يخلط خدمة السجل بتطبيقات الويب ويعاني تفاوتاً في استخدام TLS، وأن TCP المباشر لا يمنح تفاوض المعلمات اللازم لعميل يتبع إحالات بين خوادم مختلفة. هذا تبرير تصميمي، لا قياس تفوق تشغيلي.

جمع URI الخاص بملف BEEP بين إصدار مخطط IRIS وURN لنوع السجل. ويمكن عرض عدة عناصر profile عند إنشاء القناة للتفاوض على الإصدار لكل نوع مخدوم. بعد قبول الملف وإنشاء القناة، تصبح جاهزة لتبادل رسائل IRIS، ويلتزم الخادم بمعالجة استعلامات كل الأنواع التي أعلنها على القنوات المفتوحة بهذا الملف.

لكن المعالجة ليست منحاً للبيانات. في النمط الافتراضي يرسل العميل XML صالحاً لـ IRIS داخل MSG، ويرد الخادم بـ XML داخل RPY، ويستخدم ERR لأعطال BEEP. ويجوز لنوع السجل تعريف نمط آخر متوافق، لكنه يجب أن يدعم الافتراضي مع lookupEntity. وتبقى طبقة نواة IRIS وحالها الوثائقية قادرة على رفض الإذن أو إعلان أن الاستعلام غير مدعوم. الجاهزية تسمح بالسؤال، ولا تضمن جواباً إيجابياً.

احتاجت هوية الخادم إلى طريقة منفصلة. عند استخدام ملف ضبط TLS في BEEP، يُستحسن أن يحدد نوع السجل طريقة المصادقة الخاصة به؛ وإلا استُخدمت الطريقة الأساسية. يقدم العميل اسم authority المطلوب عبر serverName. ويعرض الخادم شهادة X.509 تحتوي الاسم. ثم يتحقق العميل من الشهادة تشفيرياً وفق TLS، وبعد ذلك يطابق الاسم مع dNSName وأشكال subjectDN المحددة.

الشهادة الصحيحة تشفيرياً قد تخص اسماً آخر، والاسم المطابق داخل شهادة غير موثقة ليس هوية. لذلك تفصل الطريقة بين صلاحية الاعتماد وبين تمثيله للجهة التي قصدها العميل.

ألزمت قائمة تعريف نوع السجل كل مواصفة بإعلان نمط الرسائل وإحدى سياسات مصادقة الخادم: طريقة خاصة، أو الطريقة الأساسية، أو تصريح بعدم وجود مصادقة خادم. وهكذا قد يكون ملف IRIS مقبولاً والقناة جاهزة ضمن نوع اختار صراحة ألا يصادق الخادم.

أما المستخدم فله طبقة أخرى. أدرجت RFC 3983 ملفي SASL DIGEST-MD5 وOTP لمصادقة المستخدم من دون تشفير الجلسة. وميّزت استعمال TLS للتشفير فقط عن استعماله مع شهادة عميل لإضافة مصادقة المستخدم. ويمكن أن يكون الوصول مجهولاً من دون تشغيل ملف مصادقة، أو عبر SASL ANONYMOUS. لذلك لا يساوي التشفير مصادقة المستخدم، ولا تساوي مصادقة الخادم مصادقة المستخدم، ولا تمنح هوية المستخدم إذناً تلقائياً بالنتيجة.

جاءت هذه التركيبة من BEEP. فقد عرّفت RFC 3080 وصفحة حالتها وتصويباتها وملف Datatracker الملفات والقنوات والرسائل والضبط. وربطت RFC 3081 وحالتها BEEP بـ TCP. تغيير خاصية أمنية واحدة لا يثبت سائر الخصائص.

تحدد وثائق تلك المرحلة الآليات المتاحة. فقد وصفت RFC 2246 وحالتها TLS 1.0، وقدمت RFC 2222 وصفحة حالتها إطار SASL المذكور. ووثقت RFC 2817 مع حالتها، وRFC 2818 مع حالتها، طريقتي HTTP/TLS اللتين ناقشتهما RFC 3983. وجود الآلية لا يثبت استخدامها الصحيح في جلسة بعينها.

عند الإحالة، حذرت المواصفة من إعطاء بيانات اعتماد المستخدم إلى خوادم غير موثوقة، ونصحت بعدم استخدام SASL PLAIN، ومنعت استخدامه قبل تشفير جلسة TCP. يحمي التشفير السر أثناء النقل، لكنه لا يجعل المستقبل مستحقاً له.

أضافت RFC 4992 وصفحة حالتها لاحقاً نقل XPC فوق TCP وحدّثت النواة. يثبت ذلك قابلية استبدال النقل، ولا يثبت سبب تبنٍ أو تخلٍ.

لا يزال سجل IANA لمخططات URI يحتفظ بـ iris.beep، ويحفظ سجل IANA لمعاملات BEEP فضاءات الملفات والضبط. هذه تسجيلات بروتوكولية، لا إيصالات قناة أو هوية أو إذن أو نتيجة.

القيمة التاريخية في RFC 3983 أنها أبقت الجاهزية محدودة: القناة قادرة على الرسائل. لم تجعلها مرادفاً للثقة أو الإذن أو نجاح الطلب. وكل نظام يدمج هذه الحالات في إشارة واحدة يفقد الأدلة التي يحتاجها عند انتقال العميل إلى الخادم التالي.

Sources