تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يصف هذا المستند أنواع التجوال اللاسلكية والسريعة التأمين المتاحة لشبكات IEEE 802.11 المحلية اللاسلكية (WLANs) على الشبكة اللاسلكية الموحدة (CUWN).
توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:
تستند المعلومات الواردة في هذا المستند إلى برنامج Cisco WLAN Controller Software، الإصدار 7.4.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
تستند المعلومات الواردة في هذا المستند إلى برنامج Cisco WLAN Controller Software، الإصدار 7.4، ولكن يمكن تطبيق معظم مخرجات تصحيح الأخطاء والسلوكيات الموضحة على أي إصدار برنامج يدعم الطرق التي تمت مناقشتها. تبقى تفاصيل جميع الطرق الموضحة هنا هي نفسها في رموز وحدة التحكم في الشبكة المحلية اللاسلكية (WLAN) من Cisco لاحقا (حتى الإصدار 8.3 عند تحديث هذه المقالة).
يصف هذا المستند الأنواع المختلفة من طرق التجوال اللاسلكي والتجوال السريع الآمن المتاحة لشبكات IEEE 802.11 المحلية اللاسلكية (WLANs) المدعومة على شبكة Cisco اللاسلكية الموحدة (CUWN).
لا توفر الوثيقة جميع التفاصيل حول كيفية عمل كل طريقة أو كيفية تكوينها. الغرض الأساسي من هذا المستند هو وصف الفروق بين التقنيات المختلفة المتاحة، وفوائدها وحدودها، وتبادل الإطارات على كل طريقة. يتم توفير أمثلة على تصحيح أخطاء وحدة تحكم الشبكة المحلية اللاسلكية (WLC)، ويتم إستخدام صور الحزم اللاسلكية لتحليل الأحداث التي تحدث لكل طريقة تجوال موصوفة وشرحها.
قبل تقديم وصف لمختلف طرق التجوال السريعة التأمين المتاحة لشبكات WLAN، من المهم فهم كيفية عمل عملية اقتران WLAN، وكيفية حدوث حدث تجوال عادي عند عدم تكوين تأمين على معرف مجموعة الخدمة (SSID).
عندما يتصل عميل لاسلكي 802. 11 بنقطة وصول (AP)، قبل أن يبدأ في تمرير حركة مرور البيانات (إطارات البيانات اللاسلكية)، يجب أولا أن يجتاز عملية مصادقة النظام المفتوح الأساسية 802. 11. بعد ذلك، يجب إكمال عملية الاقتران. تشبه عملية مصادقة النظام المفتوحة اتصال الكبل في نقطة الوصول التي يحددها العميل. وهذه نقطة مهمة للغاية، لأن العميل اللاسلكي هو دائما من يحدد نقطة الوصول المفضلة، ويبني القرار على عوامل متعددة تختلف بين الموردين. ولهذا السبب يبدأ العميل هذه العملية بإرسال إطار المصادقة إلى نقطة الوصول المحددة، كما هو موضح لاحقا في هذا المستند. لا يمكن لنقطة الوصول أن تطلب منك إنشاء اتصال.
بمجرد اكتمال عملية مصادقة النظام المفتوح بنجاح مع إستجابة من نقطة الوصول (AP) ("الكبل متصل")، تنتهي عملية الاقتران بشكل أساسي من تفاوض 802.11 من الطبقة 2 (L2) الذي يؤسس الارتباط بين العميل ونقطة الوصول. تقوم نقطة الوصول بتعيين معرف اقتران للعميل في حالة نجاح الاتصال، وتقوم بتجهيزه من أجل تمرير حركة المرور أو تنفيذ أسلوب تأمين عالي المستوى في حالة تكوينه على SSID. تتألف عملية مصادقة النظام المفتوح من إطارين للإدارة بالإضافة إلى عملية الاقتران. المصادقة وإطارات الاقتران هي إطارات إدارة لاسلكية، وليست إطارات بيانات، وهي أساسا الإطارات المستخدمة لعملية الاتصال بنقطة الوصول (AP).
فيما يلي صورة للإطارات اللاسلكية عبر الهواء لهذه العملية:
ملاحظة: إذا كنت تريد معرفة المزيد عن تشذيب 802.11 اللاسلكي، وحول المرشحات/الألوان المستخدمة على Wireshark للصور التي تظهر في هذا المستند، فعليك زيارة منشور مجتمع دعم Cisco الذي يسمى تحليل صورة sniffer 802.11.
يبدأ العميل اللاسلكي بإطار المصادقة، وترد نقطة الوصول بإطار مصادقة آخر. يرسل العميل بعد ذلك إطار طلب الاقتران، وتنتهي نقطة الوصول في رد باستخدام إطار "إستجابة الاقتران". كما هو موضح من حزم DHCP، بمجرد تمرير عمليات مصادقة النظام المفتوح 802.11 والاقتران، يبدأ العميل في تمرير إطارات البيانات. في هذه الحالة، لا يوجد طريقة أمان مكونة على SSID، لذلك يبدأ العميل على الفور بإرسال إطارات البيانات (في هذه الحالة DHCP) التي لا يتم تشفيرها.
كما هو موضح لاحقا في هذا المستند، في حالة تمكين الأمان على SSID، فهناك إطارات مصادقة وتشفير أعلى مستوى لطريقة الأمان المحددة، بعد إستجابة الاقتران مباشرة وقبل إرسال أي إطارات بيانات حركة مرور عميل، مثل DHCP وبروتوكول تحليل العنوان (ARP) وحزم التطبيقات التي يتم تشفيرها. يمكن إرسال إطارات البيانات فقط حتى تتم مصادقة العميل بالكامل، ويتم التفاوض على مفاتيح التشفير، استنادا إلى طريقة الأمان التي تم تكوينها.
بناء على الصورة السابقة، فيما يلي الرسائل التي تراها في مخرجات أمر عميل تصحيح أخطاء WLC عندما يبدأ العميل اللاسلكي اقتران جديد بالشبكة المحلية اللاسلكية (WLAN):
*apfMsConnTask_0: Jun 21 18:55:14.221: 00:40:96:b7:ab:5c
Association received from mobile on BSSID 84:78:ac:f0:68:d0
!--- This is the Association Request from the wireless client
to the selected AP.
*apfMsConnTask_0: Jun 21 18:55:14.222: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d0
(status 0) ApVapId 1 Slot 0
!--- This is the Association Response from the AP to the client.
ملاحظة: تصحيح أخطاء WLC المستخدم للمخرجات الموضحة في هذا المستند هو الأمر debug client، وتظهر الأمثلة بعض الرسائل ذات الصلة فقط، وليس الإخراج بالكامل. لمزيد من التفاصيل حول أمر تصحيح الأخطاء هذا، راجع المستند المسمى فهم عميل تصحيح الأخطاء على وحدات التحكم في الشبكة المحلية اللاسلكية (WLCs).
تظهر هذه الرسائل إطارات الاستجابة وطلب الاقتران؛ لا يتم تسجيل إطارات المصادقة الأولية في عنصر التحكم في الشبكة المحلية اللاسلكية (WLC) لأن عملية المصافحة هذه تحدث بسرعة على مستوى نقطة الوصول على CUWN.
اية معلومات تظهر عندما يجول الزبون؟ يتبادل العميل دائما أربعة إطارات إدارية عند تأسيس اتصال بنقطة وصول، والذي يرجع إما إلى تأسيس العميل للاقتران أو إلى حدث تجوال. لم يتم إنشاء سوى اتصال واحد للعميل لنقطة وصول واحدة فقط في كل مرة. الفرق الوحيد في تبادل الإطارات بين اتصال جديد بالبنية الأساسية للشبكة المحلية اللاسلكية (WLAN) وحدث تجوال هو أن إطارات الاقتران الخاصة بحدث تجوال تسمى إطارات إعادة التعيين، والتي تشير إلى أن العميل يقوم بالتجوال من نقطة وصول أخرى دون محاولة إنشاء اقتران جديد بالشبكة المحلية اللاسلكية (WLAN). يمكن أن تحتوي هذه الإطارات على عناصر مختلفة يتم إستخدامها للتفاوض على حدث التجوال؛ يعتمد ذلك على الإعداد، ولكن هذه التفاصيل خارج نطاق هذا المستند.
فيما يلي مثال على تبادل الإطارات:
تظهر هذه الرسائل في إخراج تصحيح الأخطاء:
*apfMsConnTask_2: Jun 21 19:02:19.709: 00:40:96:b7:ab:5c
Reassociation received from mobile on BSSID 84:78:ac:f0:2a:90
!--- This is the Reassociation Request from the wireless client
to the selected AP.
*apfMsConnTask_2: Jun 21 19:02:19.710: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:90
(status 0) ApVapId 1 Slot 0
!--- This is the Reassociation Response from the AP to the client.
كما هو موضح، يقوم العميل بنجاح بتنفيذ حدث تجوال بعد إرسال طلب إعادة التعيين إلى نقطة الوصول الجديدة، ويستلم إستجابة إعادة التعيين من نقطة الوصول. بما أن العميل لديه عنوان IP بالفعل، فإن إطارات البيانات الأولى هي لحزم ARP.
إذا كنت تتوقع حدثا متنقلا، ولكن العميل يرسل طلب اقتران بدلا من طلب إعادة تعيين (والذي يمكنك تأكيده من بعض الصور وتصحيح الأخطاء المشابهة لتلك الموضحة مسبقا في هذا المستند)، فلن يكون العميل يجول بشكل فعلي. يبدأ العميل اقتران جديد بالشبكة المحلية اللاسلكية (WLAN) كما لو كان قد حدث قطع اتصال، ويحاول إعادة الاتصال من البداية. وقد يحدث ذلك لأسباب متعددة، مثل عندما يبتعد العميل عن مناطق التغطية ثم يجد نقطة وصول ذات جودة إشارة كافية لبدء الاقتران، ولكنها تشير عادة إلى مشكلة في العميل لا يبدأ فيها حدث تجوال بسبب مشاكل في برامج التشغيل أو البرامج الثابتة أو البرامج.
ملاحظة: يمكنك التحقق من مورد العميل اللاسلكي لتحديد سبب المشكلة.
في حالة تكوين SSID باستخدام مستوى تأمين أعلى من المستوى L2 بالإضافة إلى مصادقة نظام 802.11 الأساسية المفتوحة، يتطلب الأمر مزيدا من الإطارات للاقتران الأولي والتجوال. يتم وصف طريقتي الأمان الأكثر شيوعا اللتين تم توحيدهما وتطبيقهما لشبكات 802.11 WLAN في هذه الوثيقة:
ومن المهم معرفة أنه على الرغم من أن هاتين الطريقتين (PSK و EAP) تثبتان/تحققان من صحة العملاء بطرق مختلفة، فإن كليهما يستخدم أساسا نفس قواعد WPA/WPA2 لعملية إدارة المفاتيح. سواء كان التأمين WPA/WPA2-PSK أو WPA/WPA2-EAP، فإن العملية المعروفة باسم WPA/WPA2 المصافحة رباعية الإتجاه تبدأ التفاوض الرئيسي بين WLC/AP والعميل بمفتاح جلسة رئيسي (MSK) كمادة أساسية أصلية بمجرد أن يتم التحقق من صحة العميل باستخدام طريقة مصادقة محددة مستخدمة.
فيما يلي ملخص للعملية:
عند إجراء WPA-PSK أو WPA2-PSK عبر بروتوكول سلامة المفاتيح المؤقتة (TKIP) أو معيار التشفير المتقدم (AES) للتشفير، يجب على العميل المرور بالعملية المعروفة باسم مصافحة WPA 4 في الإتجاه لكل من الاقتران الأولي وأيضا عند التجوال. وكما سبق شرحه، فإن هذه هي أساسا عملية إدارة المفاتيح المستخدمة لاستخلاص مفاتيح التشفير من WPA/WPA2. ومع ذلك، عند إجراء PSK، يتم إستخدامه أيضا للتحقق من أن العميل لديه مفتاح مشترك مسبقا صالح للانضمام إلى شبكة WLAN. تبين هذه الصورة عملية الاقتران الأولية عند تنفيذ WPA أو WPA2 مع PSK:
كما هو موضح، بعد مصادقة النظام المفتوح وفقا لمعيار 802.11 وعملية الاقتران، توجد أربعة إطارات EAPOL من مصافحة WPA رباعية الاتجاهات، والتي يتم استهلالها من قبل نقطة الوصول مع الرسالة-1، وينتهي منها من قبل العميل باستخدام الرسالة-4. بعد مصافحة ناجحة، يبدأ العميل بتمرير إطارات البيانات (مثل DHCP)، والتي يتم تشفيرها في هذه الحالة بالمفاتيح المشتقة من مصافحة رباعية الإتجاه (ولهذا السبب لا يمكنك رؤية المحتوى الفعلي لحركة مرور البيانات ونوعها من الصور اللاسلكية).
ملاحظة: يتم إستخدام إطارات EAPOL لنقل جميع إطارات الإدارة الأساسية وإطارات المصادقة 802.1X/EAP عبر الهواء بين نقطة الوصول والعميل، ويتم إرسالها كإطارات بيانات لاسلكية.
تظهر هذه الرسائل في مخرجات تصحيح الأخطاء:
*apfMsConnTask_0: Jun 21 19:30:05.172: 00:40:96:b7:ab:5c
Association received from mobile on BSSID 84:78:ac:f0:68:d1
*apfMsConnTask_0: Jun 21 19:30:05.173: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d1
(status 0) ApVapId 2 Slot 0
!--- The Association handshake is finished.
*dot1xMsgTask: Jun 21 19:30:05.178: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
!--- Message-1 of the WPA/WPA2 4-Way handshake is sent
from the WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.289: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.289: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
!--- Message-2 of the WPA/WPA2 4-Way handshake is successfully
received from the client.
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.290: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- Message-3 of the WPA/WPA2 4-Way handshake is sent
from the WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.309: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 19:30:05.310: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
!--- Message-4 (final message) of the WPA/WPA2 4-Way handshake
is successfully received from the client, which confirms
the installation of the derived keys. They can now be used in
order to encrypt data frames with current AP.
عند التجوال، يتعقب العميل بشكل أساسي نفس عملية تبادل الإطارات، حيث يلزم مصافحة WPA 4-way من أجل اشتقاق مفاتيح تشفير جديدة مع نقطة الوصول الجديدة. ويرجع ذلك إلى الأسباب الأمنية التي أرساها المعيار، وإلى أن نقطة الوصول الجديدة لا تعرف المفاتيح الأصلية. الفرق الوحيد هو أن هناك إطارات إعادة تشكيل بدلا من إطارات الاقتران، كما هو موضح في هذه الصورة:
سترى الرسائل نفسها في مخرجات تصحيح الأخطاء، ولكن الحزمة الأولى من العميل هي إعادة تعيين بدلا من اقتران، كما هو موضح ومشرح مسبقا.
عند إستخدام طريقة 802. 1X/EAP لمصادقة العملاء على SSID آمن، هناك المزيد من الإطارات المطلوبة قبل أن يبدأ العميل في تمرير حركة مرور البيانات. يتم إستخدام هذه الإطارات الإضافية لمصادقة بيانات اعتماد العميل، وتبعا لطريقة EAP، يمكن أن يكون هناك بين أربعة وعشرين إطارا. وتأتي هذه بعد الاقتران/إعادة الاندماج، ولكن قبل مصافحة WPA/WPA2 4-way، لأن مرحلة المصادقة تستمد MSK المستخدم كبداية لإنشاء مفتاح التشفير النهائي في عملية إدارة المفاتيح (المصافحة بأربعة طرق).
تعرض هذه الصورة مثالا للإطارات المتبادلة عبر الهواء بين نقطة الوصول والعميل اللاسلكي في الاقتران الأولي عند تنفيذ WPA مع PEAPv0/EAP-MSCHAPv2:
في بعض الأحيان، يظهر هذا التبادل إطارات أكثر أو أقل، والتي تعتمد على عوامل متعددة، مثل طريقة EAP، أو إعادة الإرسال بسبب مشاكل، أو سلوك العميل (مثل طلبي الهوية في هذا المثال، لأن العميل يرسل بداية EAPOL بعد أن ترسل نقطة الوصول أول طلب هوية)، أو إذا كان العميل قد تبادل الشهادة مع الخادم بالفعل. كلما تم تكوين SSID لطريقة 802.1X/EAP، هناك المزيد من الإطارات (للمصادقة)، وبالتالي، فإنه يتطلب المزيد من الوقت قبل أن يبدأ العميل في إرسال إطارات البيانات.
هنا ملخص لرسائل تصحيح الأخطاء:
*apfMsConnTask_0: Jun 21 23:41:19.092: 00:40:96:b7:ab:5c
Association received from mobile on BSSID 84:78:ac:f0:68:d8
*apfMsConnTask_0: Jun 21 23:41:19.094: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d8
(status 0) ApVapId 9 Slot 0
!--- The Association handshake is finished.
*dot1xMsgTask: Jun 21 23:41:19.098: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 1)
!--- The EAP Identity Request is sent to the client once it is
associated in order to begin the higher-level authentication
process. This informs the client that an identity to start
this type of 802.1X/EAP authentication must be provided.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.226: 00:40:96:b7:ab:5c
Received EAPOL START from mobile 00:40:96:b7:ab:5c
!--- The wireless client decides to start the EAP authentication
process, and informs the AP with an EAPOL START data frame.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.227: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
!--- WLC/AP sends another EAP Identity Request to the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.235: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.235: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c
!--- The client responds with an EAP Identity Response on an EAPOL
frame.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.301: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.301: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
!--- Once the WLC/AP sends the client response to the Authentication
Server on a RADIUS Access-Request packet, the server responds
with a RADIUS Access-Challenge in order to officially start the
EAP negotiation, handshake, and authentication with the client
(sometimes with mutual authentication, dependent upon the EAP
method). This response received by the WLC/AP is sent to the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.344: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.344: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
!--- The client responds with an EAP Response on an EAPOL frame, which
is sent to the Authentication Server on a RADIUS Access-Request
packet. The server responds with another RADIUS Access-Challenge.
This process continues, dependent upon the EAP method (the exchange
of certificates when used, the building of TLS tunnels, validation
of client credentials, client validation of server identity when
applicable). Hence, the next few messages are basically the same on
the WLC/AP side, as this acts as a "proxy" between the client and
the Authentication Server exchanges.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.347: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.347: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 4)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.375: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.375: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 4, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.377: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.377: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 5)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.403: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.403: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 5, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.404: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.404: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 6)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.414: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.414: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 6, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.421: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.421: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.425: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.425: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 7, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.427: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.427: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 8)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.434: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.434: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 8, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.436: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.436: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 9)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.440: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.440: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 9, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.442: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.442: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 10)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.449: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.449: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 10, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.452: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.452: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 11)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.457: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.457: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 11, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.459: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.459: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 13)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.469: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.469: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 13, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.472: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
!--- The authentication finishes and is successful for this client,
so the RADIUS Server sends a RADIUS Access-Accept to the WLC/AP.
This RADIUS Access-Accept comes with the special attributes
that are assigned to this client (if any are configured on the
Authentication Server for this client). This Access-Accept also
comes with the MSK derived with the client in the EAP
authentication process, so the WLC/AP installs it in order to
initiate the WPA/WPA2 4-Way handshake with the wireless client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.473: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c
(EAP Id 13)
!--- The accept/pass of the authentication is sent to the client as
an EAP-Success message.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.473: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
!--- Message-1 of the WPA/WPA2 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
!--- Message-2 of the WPA/WPA-2 4-Way handshake is successfully
received from the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.481: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- Message-3 of the WPA/WPA2 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.487: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:41:19.487: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
!--- Message-4 (final message) of the WPA/WPA2 4-Way handshake
is successfully received from the client, which confirms the
installation of the derived keys. They can now be used in
order to encrypt data frames with the current AP.
عندما يجري العميل اللاسلكي تجوال عادي هنا (السلوك العادي دون تطبيق أسلوب تجوال سريع التأمين)، يجب على العميل المرور بنفس العملية وإجراء مصادقة كاملة مقابل خادم المصادقة كما هو موضح في الصور. الفرق الوحيد هو أن العميل يستخدم طلب إعادة اشتراك لإعلام نقطة الوصول الجديدة بأنها تقوم بالفعل بالتجوال من نقطة وصول أخرى، ولكن ما يزال يتعين على العميل المرور بالتحقق الكامل وإنشاء مفتاح جديد:
كما هو موضح، حتى في حالة وجود إطارات أقل من تلك الموجودة في المصادقة الأولية (والتي تتسبب فيها عوامل متعددة كما هو مذكور سابقا)، فإنه في حالة تجول العميل إلى نقطة وصول جديدة، فإنه يجب إتمام عمليات مصادقة EAP وإدارة مفاتيح WPA للاستمرار في تمرير إطارات البيانات (حتى في حالة إرسال حركة مرور البيانات بشكل نشط قبل التجوال). لذلك، إذا كان لدى العميل تطبيق نشط حساس للتأخيرات (مثل تطبيقات حركة مرور الصوت، أو التطبيقات الحساسة للمهلات)، فيمكن للمستخدم إدراك المشاكل عند التجوال، مثل الثغرات الصوتية أو قطع اتصال التطبيق. يعتمد هذا على المدة التي تستغرقها العملية لكي يستمر العميل في إرسال/إستقبال إطارات البيانات. يمكن أن يكون هذا التأخير أطول، معتمدا على: بيئة التردد اللاسلكي، ومقدار العملاء، ووقت الذهاب والعودة بين WLC و LAPs ومع خادم المصادقة، وأسباب أخرى.
فيما يلي ملخص لرسائل تصحيح الأخطاء الخاصة بهذا الحدث المتجول (وهي أساسا نفس الرسائل السابقة، لذا لا يتم وصف هذه الرسائل أكثر):
*apfMsConnTask_2: Jun 21 23:47:54.872: 00:40:96:b7:ab:5c
Reassociation received from mobile on BSSID 84:78:ac:f0:2a:98
*apfMsConnTask_2: Jun 21 23:47:54.874: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:98
(status 0) ApVapId 9 Slot 0
*dot1xMsgTask: Jun 21 23:47:54.879: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 1)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
Received EAPOL START from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
dot1x - moving mobile 00:40:96:b7:ab:5c intoConnecting
state
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.895: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.922: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.929: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.941: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.943: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 4)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.954: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 4, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.956: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.957: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.976: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 7, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c
(EAP Id 7)
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.978: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:54.995: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 23:47:55.005: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
هذه هي الطريقة التي يعمل بها 802. 1X/EAP و WPA/WPA2 إطار عمل الأمان. لمنع تأثير التطبيق/الخدمة على التأخير من حدث تجوال منتظم، تقوم صناعة WiFi بتطوير وتنفيذ العديد من طرق التجوال السريعة التأمين من أجل تسريع عملية التجوال عند إستخدام التأمين على الشبكة المحلية اللاسلكية (WLAN)/SSID. يواجه العملاء بعض التأخير عند استمرارهم في تمرير حركة المرور أثناء التجوال بين نقاط الوصول من خلال نشر أمان عالي المستوى على الشبكة المحلية اللاسلكية (WLAN). يرجع ذلك إلى مصادقة EAP وعمليات تبادل إطارات إدارة المفاتيح المطلوبة من إعداد الأمان، كما هو موضح مسبقا.
من المهم أن تفهم أن التجوال السريع الآمن هو مجرد مصطلح تستخدمه الصناعة بالإشارة إلى تنفيذ طريقة/نظام يسرع عملية التجوال عندما يتم تكوين الأمان على الشبكة المحلية اللاسلكية (WLAN). يتم شرح مختلف طرق/مخططات التجوال السريعة التأمين المتاحة لشبكات WLAN، والمدعومة من قبل CUWN، في القسم التالي.
إدارة المفاتيح المركزية من Cisco (CCKM) هي أول طريقة تجوال سريعة الأمان يتم تطويرها وتنفيذها على شبكات WLAN الخاصة بالمؤسسات، والتي تم إنشاؤها بواسطة Cisco كحل يستخدم للحد من التأخيرات التي تم شرحها حتى الآن، عند إستخدام أمان 802.1X/EAP على شبكة WLAN. بما أن هذا بروتوكول خاص من Cisco، فإنه مدعوم فقط من قبل أجهزة البنية الأساسية WLAN من Cisco والعملاء اللاسلكيين (من عدة موردين) المتوافقين مع Cisco Compatible Extension (CCX) ل CCKM.
يمكن تنفيذ CCKM باستخدام جميع طرق التشفير المختلفة المتاحة للشبكات المحلية اللاسلكية، لتضمين WEP و TKIP و AES. كما يتم دعمه بمعظم طرق مصادقة 802.1X/EAP المستخدمة لشبكات WLAN، اعتمادا على إصدار CCX المدعوم من الأجهزة.
ملاحظة: للحصول على نظرة عامة على محتوى الميزة المدعوم من الإصدارات المختلفة من مواصفات CCX (التي تتضمن أساليب EAP المدعومة)، قم بالرجوع إلى مستند إصدارات CCX وميزاته، وتحقق من إصدار CCX الدقيق الذي يدعمه عملاؤك اللاسلكيون (إذا كانوا متوافقين مع CCX)، بحيث يمكنك تأكيد ما إذا كان يمكن تنفيذ طريقة الأمان التي ترغب في إستخدامها مع CCKM.
تقدم هذه الصورة اللاسلكية مثالا عن الإطارات المتبادلة عند الاقتران المبدئي عند أداء CCKM مع TKIP كتشفير، و PEAPv0/EAP-MSCHAPv2 كطريقة 802.1X/EAP. هذا هو أساسا نفس التبادل كما لو كان WPA/TKIP مع PEAPv0/EAP-MSCHAPv2 يتم إجراؤه، ولكن هذه المرة CCKM بين العميل والبنية الأساسية يتم التفاوض عليها بحيث يستخدمون مختلف التسلسل الهرمي للمفتاح وطرق ذاكرة التخزين المؤقت من أجل تنفيذ التجوال الآمن السريع عندما يتوجب على العميل التجوال:
فيما يلي ملخص لرسائل تصحيح الأخطاء (مع إزالة بعض عمليات تبادل EAP لتقليل المخرجات):
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
Association received from mobile on BSSID 84:78:ac:f0:68:d3
!--- This is the Association Request from the client.
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
Processing WPA IE type 221, length 22 for mobile
00:40:96:b7:ab:5c
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
CCKM: Mobile is using CCKM
!--- The WLC/AP finds an Information Element that claims CCKM
support on the Association request that is sent from the client.
*apfMsConnTask_0: Jun 25 15:41:41.507: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
!--- This is the key cache index for this client, which is set temporally.
*apfMsConnTask_0: Jun 25 15:41:41.508: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d3
(status 0) ApVapId 4 Slot 0
!--- The Association Response is sent to the client.
*dot1xMsgTask: Jun 25 15:41:41.513: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 1)
!--- An EAP Identity Request is sent to the client once it is
associated in order to begin the higher-level authentication
process. This informs the client that an identity to start
this type of 802.1X/EAP authentication must be provided.
Further EAP messages are not described, as they are basically
the same as the ones previously-explained.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.536: 00:40:96:b7:ab:5c
Received EAPOL START from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.536: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.546: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.546: 00:40:96:b7:ab:5c
Received EAP Response packet with mismatching id
(currentid=2, eapid=1) from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.550: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.550: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile
00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.555: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.555: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.594: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.594: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.840: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Creating a PKC PMKID Cache entry for station 00:40:96:b7:ab:5c
(RSN 0)<br/ >
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
CCKM: Create a global PMK cache entry
!--- WLC creates a global PMK cache entry for this client,
which is for CCKM in this case.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c
(EAP Id 13)
!--- The client is informed of the successful EAP authentication.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.841: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
INITPMK(message 1),replay counter 00.00.00.00.00.00.00.00
!--- Message-1 of the initial 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2) from mobile
00:40:96:b7:ab:5c
!--- Message-2 of the initial 4-Way handshake is received
successfully from the client.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
CCKM: Sending cache add
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: CCKM: Sending CCKM PMK
(Version_1) information to mobility group
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: CCKM: Sending CCKM PMK
(Version_2) information to mobility group
!--- The CCKM PMK cache entry for this client is shared with
the WLCs on the mobility group.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.858: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- Message-3 of the initial 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.866: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 25 15:41:41.866: 00:40:96:b7:ab:5c Received
EAPOL-key in PTKINITNEGOTIATING state (message 4) from mobile
00:40:96:b7:ab:5c
!--- Message-4 (final message) of this initial 4-Way handshake
is received successfully from the client, which confirms the
installation of the derived keys. They can now be used in order
to encrypt data frames with the current AP.
مع CCKM، يكون الربط الأولي إلى WLAN مماثل إلى WPA/WPA2 العادي، حيث MSK (المعروف أيضا هنا باسم Network Session Key (NSK)) مشتق بشكل متبادل مع العميل وخادم RADIUS. يتم إرسال هذا المفتاح الأساسي من الخادم إلى عنصر التحكم في الشبكة المحلية اللاسلكية (WLC) بعد مصادقة ناجحة، ويتم تخزينه مؤقتا كأساس لاشتقاق جميع المفاتيح التالية طوال فترة بقاء اقتران العميل بشبكة WLAN هذه. من هنا، يستخرج عنصر التحكم في الشبكة المحلية اللاسلكية (WLC) والعميل معلومات البداية التي يتم إستخدامها للتجوال الآمن السريع استنادا إلى CCKM، يمر هذا من خلال مصافحة رباعية الاتجاهات مماثلة لتلك الخاصة ب WPA/WPA2، من أجل إستخراج مفاتيح تشفير البث الأحادي (PTK) والبث المتعدد (GTK) باستخدام نقطة الوصول الأولى.
يلاحظ الفرق الكبير عند التجوال. في هذه الحالة، يرسل عميل CCKM إطار طلب إعادة إستدعاء وحيد إلى ال AP/WLC (أن يتضمن MIC ورقم عشوائي يتزايد بشكل تسلسلي)، ويوفر معلومات كافية (أن يتضمن ال ap {upper}mac address -BSSID-) in order to استخرج ال PTK جديد. مع هذا طلب إعادة توزيع، ال WLC و AP جديد أيضا يتلقى ما يكفي من المعلومات in order to استخرجت ال PTK جديد، لذلك هم ببساطة ردوا مع إعادة تشكيل إستجابة. يمكن للعميل الآن متابعة نقل البيانات، كما هو موضح في هذه الصورة:
فيما يلي ملخص للتصحيحات الخاصة بعنصر التحكم في الشبكة المحلية اللاسلكية (WLC) لهذا الحدث المتجول:
*apfMsConnTask_2: Jun 25 15:43:33.749: 00:40:96:b7:ab:5c
CCKM: Received REASSOC REQ IE
*apfMsConnTask_2: Jun 25 15:43:33.749: 00:40:96:b7:ab:5c
Reassociation received from mobile on BSSID
84:78:ac:f0:2a:93
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
Processing WPA IE type 221, length 22 for mobile
00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
CCKM: Mobile is using CCKM
!--- The Reassociation Request is received from the client,
which provides the CCKM information needed in order to
derive the new keys with a fast-secure roam.
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
Setting active key cache index 0 ---> 8
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
CCKM: Processing REASSOC REQ IE
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
CCKM: using HMAC MD5 to compute MIC
!--- WLC computes the MIC used for this CCKM fast-roaming
exchange.
*apfMsConnTask_2: Jun 25 15:43:33.750: 00:40:96:b7:ab:5c
CCKM: Received a valid REASSOC REQ IE
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
CCKM: Initializing PMK cache entry with a new PTK
!--- The new PTK is derived.
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 0
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Creating a PKC PMKID Cache entry for station
00:40:96:b7:ab:5c (RSN 0) on BSSID 84:78:ac:f0:2a:93
!--- The new PMKID cache entry is created for this new
AP-to-client association.
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
CCKM: using HMAC MD5 to compute MIC
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Including CCKM Response IE (length 62) in Assoc Resp to mobile
*apfMsConnTask_2: Jun 25 15:43:33.751: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:93
(status 0) ApVapId 4 Slot 0
!--- The Reassociation Response is sent from the WLC/AP to
the client, which includes the CCKM information required
in order to confirm the new fast-roam and key derivation.
*dot1xMsgTask: Jun 25 15:43:33.757: 00:40:96:b7:ab:5c
Skipping EAP-Success to mobile 00:40:96:b7:ab:5c
!--- EAP is skipped due to the fast roaming, and CCKM does not
require further key handshakes. The client is now ready to
pass encrypted data frames on the new AP.
كما هو موضح، يتم إجراء التجوال السريع والآمن بينما يتم تجنب إطارات مصادقة EAP وحتى المزيد من مصافحة أربعة أتجاهات، لأن مفاتيح التشفير الجديدة لا تزال مشتقة، ولكن استنادا إلى مخطط تفاوض CCKM. ويتم إكمال ذلك باستخدام إطارات إعادة تكوين التجوال والمعلومات التي تم تخزينها مؤقتا مسبقا بواسطة العميل ووحدة التحكم في الشبكة المحلية اللاسلكية (WLC).
يعتبر التخزين المؤقت لمعرف Key (PMKID) أو التخزين المؤقت للمفاتيح اللاصقة (SKC) أول طريقة تجوال سريعة التأمين يقترحها معيار IEEE 802.11 في تعديل الأمان 802.11i، حيث يكون الغرض الرئيسي هو توحيد مستوى عال من الأمان لشبكات WLAN. تمت إضافة تقنية التجوال السريع التأمين هذه كطريقة إختيارية لأجهزة WPA2 من أجل تحسين التجوال عند تنفيذ هذا التأمين.
وهذا ممكن لأنه في كل مرة تتم مصادقة العميل بالكامل على EAP، يستمد العميل وخادم المصادقة MSK، والذي يتم إستخدامه لاستخلاص PMK. يستخدم هذا كبذرة لمصافحة WPA2 4-Way لاستخلاص مفتاح تشفير البث الأحادي النهائي (PTK) الذي يتم إستخدامه للجلسة (حتى يجول العميل إلى نقطة وصول أخرى أو تنتهي الجلسة)، ومن ثم، تمنع هذه الطريقة مرحلة مصادقة EAP عند التجوال لأنه يعيد إستخدام PMK الأصلي الذي تم تخزينه مؤقتا من قبل العميل و AP. يجب على العميل فقط إجراء تأكيد الاتصال رباعي الإتجاه WPA2 من أجل اشتقاق مفاتيح تشفير جديدة.
لا يتم نشر هذه الطريقة على نطاق واسع نظرا لطريقة التجوال القياسية الآمنة 802.11 الموصى بها ويرجع ذلك بشكل أساسي إلى هذه الأسباب:
باستخدام هذه الطريقة، يكون الاقتران الأولي بأي نقطة وصول بمثابة مصادقة عادية لأول مرة للشبكة المحلية اللاسلكية (WLAN)، حيث يجب أن تحدث المصادقة 802. 1X/EAP بالكامل مقابل خادم المصادقة والمصافحة رباعية الإتجاه لإنشاء المفتاح قبل أن يتمكن العميل من إرسال إطارات البيانات، كما هو موضح في صورة الشاشة هذه:
تكشف الأخطاء عن تبادل إطار مصادقة EAP نفسه كباقي الطرق عند المصادقة الأولية للشبكة المحلية اللاسلكية (WLAN)، مع إضافة بعض المخرجات فيما يتعلق بتقنيات التخزين المؤقت الأساسية المستخدمة هنا. يتم خفض مخرجات تصحيح الأخطاء هذه لعرض المعلومات الجديدة بشكل أساسي، وليس تبادل إطارات EAP بالكامل، لأنه يتم تبادل نفس المعلومات بشكل أساسي في كل مرة لمصادقة العميل مقابل خادم المصادقة. وهذا موضح حتى الآن، ومترابط مع إطارات مصادقة EAP الموضحة في صور الحزمة، حتى تتم إزالة معظم رسائل EAP من مخرجات تصحيح الأخطاء للتبسيط:
*apfMsConnTask_0: Jun 22 00:23:15.097: ec:85:2f:15:39:32
Association received from mobile on BSSID 84:78:ac:f0:68:d2
!--- This is the Association Request from the client.
*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32
Processing RSN IE type 48, length 20 for mobile ec:85:2f:15:39:32
!--- The WLC/AP finds an Information Element that claims PMKID
Caching support on the Association request that is sent
from the client.
*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32
Received RSN IE with 0 PMKIDs from mobile ec:85:2f:15:39:32
!--- Since this is an initial association, the Association
Request comes without any PMKID.
*apfMsConnTask_0: Jun 22 00:23:15.098: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*apfMsConnTask_0: Jun 22 00:23:15.099: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d2
(status 0) ApVapId 3 Slot 0
!--- The Association Response is sent to the client.
*dot1xMsgTask: Jun 22 00:23:15.103: ec:85:2f:15:39:32
Sending EAP-Request/Identity to mobile ec:85:2f:15:39:32
(EAP Id 1)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.118: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.118: ec:85:2f:15:39:32
Received Identity Response (count=1) from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.126: ec:85:2f:15:39:32
Processing Access-Challenge for mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.126: ec:85:2f:15:39:32
Sending EAP Request from AAA to mobile ec:85:2f:15:39:32
(EAP Id 2)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.146: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.146: ec:85:2f:15:39:32
Received EAP Response from mobile ec:85:2f:15:39:32
(EAP Id 2, EAP Type 25)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Processing Access-Accept for mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Creating a PKC PMKID Cache entry for station ec:85:2f:15:39:32
(RSN 2)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Adding BSSID 84:78:ac:f0:68:d2 to PMKID cache at index 0
for station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274:
New PMKID: (16)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- WLC creates a PMK cache entry for this client, which is
used for SKC in this case, so the PMKID is computed with
the AP MAC address (BSSID 84:78:ac:f0:68:d2).
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.274: ec:85:2f:15:39:32
Sending EAP-Success to mobile ec:85:2f:15:39:32
(EAP Id 12)
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275:
Including PMKID in M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
WPA/WPA2 4-Way handshake.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- This is the hashed PMKID.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.275: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
!--- Message-1 of the WPA/WPA2 4-Way handshake is sent from
the WLC/AP to the client.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from mobile
ec:85:2f:15:39:32
!--- Message-2 of the WPA/WPA-2 4-Way handshake is successfully
received from the client.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.284: ec:85:2f:15:39:32
PMK: Sending cache add
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.285: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32
state PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- Message-3 of the WPA/WPA2 4-Way handshake is sent from
the WLC/AP to the client.
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.291: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:23:15.291: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
!--- Message-4 (final message) of this initial WPA/WPA2 4-Way
handshake is successfully received from the client, which
confirms the installation of the derived keys. They can
now be used in order to encrypt data frames with the current AP.
باستخدام هذه الطريقة، تقوم نقاط الوصول وذاكرة التخزين المؤقت للعميل اللاسلكي بنسخ PMKs الخاصة بالاقترانات الآمنة التي تم إنشاؤها بالفعل. وبالتالي، إذا تجول العميل اللاسلكي إلى نقطة وصول جديدة لم تقترن بها قط، فيجب على العميل إجراء مصادقة EAP كاملة مرة أخرى، كما هو موضح في هذه الصورة حيث يجول العميل إلى نقطة وصول جديدة:
ومع ذلك، إذا عاد العميل اللاسلكي إلى نقطة وصول حدثت فيها اقتران/مصادقة سابقة، يرسل العميل إطار طلب إعادة تعيين يسرد العديد من PMKIDs، والذي يقوم بإعلام نقطة الوصول بمجموعات PMK المخزنة مؤقتا من جميع نقاط الوصول التي قام العميل بالمصادقة عليها مسبقا. لذلك، فبما أن العميل يجول مرة أخرى إلى نقطة وصول تحتوي أيضا على PMK مخزن مؤقتا لهذا العميل، فلا يحتاج العميل إلى إعادة المصادقة من خلال EAP لاستخراج PMK جديد. يمر العميل ببساطة بمصافحة WPA2 4-way من أجل اشتقاق مفاتيح التشفير المؤقتة الجديدة:
ملاحظة: لا تعرض هذه الصورة إطار مصادقة النظام المفتوح الأول وفقا لمعيار 802.11 من العميل، ولكن هذا لا يرجع إلى الطريقة التي تم تنفيذها، حيث إن هذا الإطار مطلوب دائما. السبب هو أن هذا الإطار المحدد لا يتم تصويره بواسطة المحول أو برنامج صورة الحزمة اللاسلكية المستخدم لشم الإطارات عبر الهواء لهذا المثال، ولكنه يترك هكذا على المثال لأغراض تعليمية. مدرك أن هناك احتمال أن هذا يمكن أن يحدث عندما تقوم بأداء صور حزم عبر الهواء، بعض الإطارات يمكن أن تفقد من قبل الصورة، لكن في الواقع يتم تبادلها بين العميل و AP. وإلا فإن التجوال لا يبدأ على هذا المثال.
فيما يلي ملخص للتصحيحات الخاصة بعنصر التحكم في الشبكة المحلية اللاسلكية (WLC) لطريقة التجوال سريعة الأمان هذه:
*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
Reassociation received from mobile on BSSID
84:78:ac:f0:68:d2
!--- This is the Reassociation Request from the client.
*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
Processing RSN IE type 48, length 38 for mobile
ec:85:2f:15:39:32
!--- The WLC/AP finds an Information Element that claims PMKID
Caching support on the Association request that is sent
from the client.
*apfMsConnTask_0: Jun 22 00:26:40.787: ec:85:2f:15:39:32
Received RSN IE with 1 PMKIDs from mobile
ec:85:2f:15:39:32
!--- The Reassociation Request from the client comes with
one PMKID.
*apfMsConnTask_0: Jun 22 00:26:40.787:
Received PMKID: (16)
*apfMsConnTask_0: Jun 22 00:26:40.788:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- This is the PMKID that is received.
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Searching for PMKID in MSCB PMKID cache for mobile
ec:85:2f:15:39:32
!--- WLC searches for a matching PMKID on the database.
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d2 in
PMKID cache at index 0 of station ec:85:2f:15:39:32
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Found a valid PMKID in the MSCB PMKID cache for mobile
ec:85:2f:15:39:32
!--- The WLC validates the PMKID provided by the client,
and confirms that it has a valid PMK cache for this
client-and-AP pair.
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Setting active key cache index 1 ---> 0
*apfMsConnTask_0: Jun 22 00:26:40.788: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID
84:78:ac:f0:68:d2(status 0) ApVapId 3 Slot 0
!--- The Reassociation Response is sent to the client, which
validates the fast-roam with SKC.
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Initiating RSN with existing PMK to mobile
ec:85:2f:15:39:32
!--- WLC initiates a Robust Secure Network association with
this client-and-AP pair based on the cached PMK found.
Hence, EAP is avoided as per the next message.
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Skipping EAP-Success to mobile ec:85:2f:15:39:32
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d2 in
PMKID cache at index 0 of station ec:85:2f:15:39:32
*dot1xMsgTask: Jun 22 00:26:40.795: Including PMKID in M1(16)
!--- The hashed PMKID is included on the Message-1 of the
WPA/WPA2 4-Way handshake.
*dot1xMsgTask: Jun 22 00:26:40.795:
[0000] c9 4d 0d 97 03 aa a9 0f 1b c8 33 73 01 f1 18 f5
!--- The PMKID is hashed. The next messages are the same
WPA/WPA2 4-Way handshake messages described thus far
that are used in order to finish the encryption keys
generation/installation.
*dot1xMsgTask: Jun 22 00:26:40.795: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.811: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from mobile
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
PMK: Sending cache add
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.812: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.820: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 22 00:26:40.820: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
يمكن تنفيذ هذه الطريقة محليا بواسطة نقاط الوصول (AP) المستقلة، دون الحاجة إلى جهاز مركزي لإدارة المفاتيح المخزنة مؤقتا.
إن التخزين المؤقت الانتهازي للمفتاح (OKC)، والمعروف أيضا باسم التخزين المؤقت الاستباقي للمفاتيح (PKC) (يتم شرح هذا المصطلح بمزيد من التفصيل في ملاحظة تعد تالية)، هو في الأساس تحسين لطريقة التخزين المؤقت WPA2 PMKID الموضحة سابقا، وهذا هو السبب وراء تسميتها أيضا التخزين المؤقت الاستباقي/الانتهازي PMKID. وبالتالي، من المهم ملاحظة أن هذه الطريقة ليست طريقة تجوال سريعة التأمين معرفة بمعيار 802.11 ولا تدعمها أجهزة كثيرة، ولكنها تعمل مع WPA2-EAP تماما مثل التخزين المؤقت ل PMKID.
يسمح هذا الأسلوب للعميل اللاسلكي والبنية الأساسية للشبكة المحلية اللاسلكية (WLAN) بتخزين PMK واحد فقط طوال العمر الافتراضي لاقتران العميل مع شبكة WLAN هذه (المستمد من MSK بعد مصادقة 802.1X/EAP الأولية مع خادم المصادقة)، حتى عند التجوال بين نقاط الوصول المتعددة، حيث أنها تشترك جميعها في PMK الأصلية التي يتم إستخدامها كبذرة على جميع رسائل WPA2 الرباعية الإتجاه. ولا يزال هذا مطلوبا، كما هو الحال في SKC، من أجل إنشاء مفاتيح تشفير جديدة في كل مرة يعيد فيها العميل الاتصال بنقاط الوصول. لكي تتمكن نقاط الوصول من مشاركة PMK الأصلي هذا من جلسة عمل العميل، يجب أن تكون جميعها تحت نوع ما من التحكم الإداري، مع جهاز مركزي يقوم بتخزين PMK الأصلي وتوزيعه لجميع نقاط الوصول. وهذا مماثل ل CUWN، حيث تقوم WLC بأداء هذه المهمة لجميع نقاط الوصول في الوضع Lightweight (LAPs) تحت التحكم فيها، وتستخدم مجموعات التنقل لمعالجة PMK هذه بين نقاط الوصول في الوضع Lightweight (WLCs) المتعددة، وبالتالي، يعد هذا قيدا على بيئات AP المستقلة.
باستخدام هذه الطريقة، تماما كما هو الحال في التخزين المؤقت PMKID (SKC)، يكون الاقتران الأولي لأي نقطة وصول مصادقة منتظمة لأول مرة للشبكة المحلية اللاسلكية (WLAN)، حيث يجب عليك إكمال مصادقة 802.1X/EAP بالكامل مقابل خادم المصادقة والمصافحة رباعية الإتجاه لإنشاء المفاتيح قبل أن تتمكن من إرسال إطارات البيانات. هنا صورة شاشة توضح هذا:
تظهر مخرجات تصحيح الأخطاء أساسا نفس تبادل إطار مصادقة EAP مثل بقية الطرق الموصوفة في هذا المستند عند المصادقة الأولية للشبكة المحلية اللاسلكية (WLAN) (كما هو موضح في الصور)، بالإضافة إلى بعض المخرجات التي تتعلق بتقنيات التخزين المؤقت الأساسية المستخدمة من قبل عنصر التحكم في الشبكة المحلية اللاسلكية (WLC) هنا. يتم خفض إخراج تصحيح الأخطاء هذا أيضا لعرض المعلومات ذات الصلة فقط:
*apfMsConnTask_0: Jun 21 21:46:06.515: 00:40:96:b7:ab:5c
Association received from mobile on BSSID
84:78:ac:f0:68:d2
!--- This is the Association Request from the client.
*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
Processing RSN IE type 48, length 20 for mobile
00:40:96:b7:ab:5c
!--- The WLC/AP finds an Information Element that claims
PMKID Caching support on the Association request that
is sent from the client.
*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
Received RSN IE with 0 PMKIDs from mobile
00:40:96:b7:ab:5c
!--- Since this is an initial association, the Association
Request comes without any PMKID.
*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
Setting active key cache index 0 ---> 8
*apfMsConnTask_0: Jun 21 21:46:06.516: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID
84:78:ac:f0:68:d2 (status 0) ApVapId 3 Slot
!--- The Association Response is sent to the client.
*dot1xMsgTask: Jun 21 21:46:06.522: 00:40:96:b7:ab:5
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 1)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.614: 00:40:96:b7:ab:5c
Received EAPOL START from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.614: 00:40:96:b7:ab:5c
Sending EAP-Request/Identity to mobile 00:40:96:b7:ab:5c
(EAP Id 2)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.623: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.623: 00:40:96:b7:ab:5c
Received Identity Response (count=2) from mobile
00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.630: 00:40:96:b7:ab:5c
Processing Access-Challenge for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.630: 00:40:96:b7:ab:5c
Sending EAP Request from AAA to mobile 00:40:96:b7:ab:5c
(EAP Id 3)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.673: 00:40:96:b7:ab:5c
Received EAPOL EAPPKT from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.673: 00:40:96:b7:ab:5c
Received EAP Response from mobile 00:40:96:b7:ab:5c
(EAP Id 3, EAP Type 25)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.843: 00:40:96:b7:ab:5c
Processing Access-Accept for mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Creating a PKC PMKID Cache entry for station
00:40:96:b7:ab:5c (RSN 2)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Adding BSSID 84:78:ac:f0:68:d2 to PMKID cache at index 0
for station 00:40:96:b7:ab:5
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: New PMKID: (16)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844:
[0000] 4e a1 7f 5a 75 48 9c f9 96 e3 a8 71 25 6f 11 d0
!--- WLC creates a PMK cache entry for this client, which is
used for OKC in this case, so the PMKID is computed
with the AP MAC address (BSSID 84:78:ac:f0:68:d2).
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
PMK sent to mobility group
!--- The PMK cache entry for this client is shared with the
WLCs on the mobility group.
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Sending EAP-Success to mobile 00:40:96:b7:ab:5c (EAP Id 13)
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Found an cache entry for BSSID 84:78:ac:f0:68:d2 in PMKID
cache at index 0 of station 00:40:96:b7:ab:5
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: Including PMKID
in M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
WPA/WPA2 4-Way handshake.
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844:
[0000] 4e a1 7f 5a 75 48 9c f9 96 e3 a8 71 25 6f 11 d0
!--- This is the hashed PMKID. The next messages are the same
WPA/WPA2 4-Way handshake messages described thus far that
are used in order to finish the encryption keys
generation/installation.
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.844: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2)
from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
PMK: Sending cache add
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.865: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.889: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:46:06.890: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
باستخدام هذه الطريقة، يقوم العميل اللاسلكي ووحدة التحكم في الشبكة المحلية اللاسلكية (WLC) (لجميع نقاط الوصول المدارة) بذاكرة التخزين المؤقت لبطاقة PMK الأصلية الوحيدة للاقتران الآمن الذي تم إنشاؤه في البداية. أساسا، في كل مرة يتصل فيها العميل اللاسلكي بنقطة وصول معينة، تتم تجزئة PMKID بناء على: عنوان MAC العميل وعنوان MAC لنقطة الوصول (BSSID من WLAN)، والحزمة PMK المشتقة من نقطة الوصول هذه. لذلك، بما أن OKC يقوم بتخزين نفس PMK الأصلي لجميع نقاط الوصول والعميل المحدد، عندما يرتبط هذا العميل (re)ب نقطة وصول أخرى، فإن القيمة الوحيدة التي تتغير من أجل تجزئة PMKID الجديد هي عنوان AP MAC الجديد.
عندما يقوم العميل ببدء التجوال إلى نقطة وصول جديدة ويرسل إطار طلب إعادة الإنشاء، فإنه يضيف PMKID على عنصر معلومات WPA2 RSN إذا كان يريد إعلام نقطة الوصول باستخدام PMK المخزنة مؤقتا للتجوال الآمن بسرعة. إنه يعرف بالفعل عنوان MAC الخاص ب BSSID (AP) لأين يجول، ثم يقوم العميل ببساطة بتقييد PMKID الجديد المستخدم في طلب إعادة التعيين هذا. عندما تتلقى نقطة الوصول هذا الطلب من العميل، فإنها تقسم أيضا PMKID بالقيم التي تمتلكها بالفعل (PMK المخزن مؤقتا وعنوان MAC للعميل وعنوان MAC الخاص به)، وتستجيب مع إستجابة إعادة الإدماج الناجحة التي تؤكد تطابق PMKIDs. يمكن إستخدام PMK المخزن مؤقتا كبذرة تبدأ مصافحة WPA2 4-Way لاستخلاص مفاتيح التشفير الجديدة (وتخطي EAP):
في هذه الصورة، يتم تحديد إطار طلب إعادة التشغيل من العميل وتوسيعه بحيث يمكنك رؤية المزيد من تفاصيل الإطار. معلومات عنوان MAC وكذلك عنصر معلومات شبكة الأمان القوية (RSN، وفقا ل 802.11i - WPA2)، حيث يتم عرض معلومات حول إعدادات WPA2 المستخدمة لهذه الاقتران (يتم التركيز على PMKID الذي تم الحصول عليه من الصيغة المحسوبة).
فيما يلي ملخص بتصحيح أخطاء عنصر التحكم في الشبكة المحلية اللاسلكية (WLC) لطريقة التجوال سريعة الأمان هذه مع OKC:
*apfMsConnTask_2: Jun 21 21:48:50.562: 00:40:96:b7:ab:5c
Reassociation received from mobile on BSSID
84:78:ac:f0:2a:92
!--- This is the Reassociation Request from the client.
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Processing RSN IE type 48, length 38 for mobile
00:40:96:b7:ab:5c
!--- The WLC/AP finds and Information Element that claims
PMKID Caching support on the Association request that
is sent from the client.
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Received RSN IE with 1 PMKIDs from mobile
00:40:96:b7:ab:5c
!--- The Reassociation Request from the client comes with
one PMKID.
*apfMsConnTask_2: Jun 21 21:48:50.563:
Received PMKID: (16)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Searching for PMKID in MSCB PMKID cache for mobile
00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
No valid PMKID found in the MSCB PMKID cache for mobile
00:40:96:b7:ab:5
!--- As the client has never authenticated with this new AP,
the WLC cannot find a valid PMKID to match the one provided
by the client. However, since the client performs OKC
and not SKC (as per the following messages), the WLC computes
a new PMKID based on the information gathered (the cached PMK,
the client MAC address, and the new AP MAC address).
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Trying to compute a PMKID from MSCB PMK cache for mobile
00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: Find PMK in cache: BSSID = (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 84 78 ac f0 2a 90
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: Find PMK in cache: realAA = (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 84 78 ac f0 2a 92
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: Find PMK in cache: PMKID = (16)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: AA (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 84 78 ac f0 2a 92
*apfMsConnTask_2: Jun 21 21:48:50.563:
CCKM: SPA (6)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 00 40 96 b7 ab 5c
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Adding BSSID 84:78:ac:f0:2a:92 to PMKID cache at
index 0 for station 00:40:96:b7:ab:5c
*apfMsConnTask_2: Jun 21 21:48:50.563:
New PMKID: (16)
*apfMsConnTask_2: Jun 21 21:48:50.563:
[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Computed a valid PMKID from MSCB PMK cache for mobile
00:40:96:b7:ab:5c
!--- The new PMKID is computed and validated to match the
one provided by the client, which is also computed with
the same information. Hence, the fast-secure roam is
possible.
*apfMsConnTask_2: Jun 21 21:48:50.563: 00:40:96:b7:ab:5c
Setting active key cache index 0 ---> 0
*apfMsConnTask_2: Jun 21 21:48:50.564: 00:40:96:b7:ab:5c
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:92
(status 0) ApVapId 3 Slot
!--- The Reassociation response is sent to the client, which
validates the fast-roam with OKC.
*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
Initiating RSN with existing PMK to mobile
00:40:96:b7:ab:5c
!--- WLC initiates a Robust Secure Network association with
this client-and AP pair with the cached PMK found.
Hence, EAP is avoided, as per the the next message.
*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
Skipping EAP-Success to mobile 00:40:96:b7:ab:5c
*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
Found an cache entry for BSSID 84:78:ac:f0:2a:92 in
PMKID cache at index 0 of station 00:40:96:b7:ab:5c
*dot1xMsgTask: Jun 21 21:48:50.570:
Including PMKID in M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
WPA/WPA2 4-Way handshake.
*dot1xMsgTask: Jun 21 21:48:50.570:
[0000] 91 65 c3 fb fc 44 75 48 67 90 d5 da df aa 71 e9
!--- The PMKID is hashed. The next messages are the same
WPA/WPA2 4-Way handshake messages described thus far,
which are used in order to finish the encryption keys
generation/installation.
*dot1xMsgTask: Jun 21 21:48:50.570: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.00
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5c
Received EAPOL-key in PTK_START state (message 2) from mobile
00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.589: 00:40:96:b7:ab:5c
PMK: Sending cache add
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.590: 00:40:96:b7:ab:5c
Sending EAPOL-Key Message to mobile 00:40:96:b7:ab:5c state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.610: 00:40:96:b7:ab:5c
Received EAPOL-Key from mobile 00:40:96:b7:ab:5c
*Dot1x_NW_MsgTask_4: Jun 21 21:48:50.610: 00:40:96:b7:ab:5c
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile 00:40:96:b7:ab:5c
كما هو موضح في بداية عمليات تصحيح الأخطاء، يجب حساب PMKID بعد تلقي طلب إعادة التعيين من العميل. يلزم هذا للتحقق من صحة PMKID وتأكيد إستخدام PMK المخزن مؤقتا مع مصافحة WPA2 4-Way لاستخلاص مفاتيح التشفير وإنهاء التجوال السريع الآمن. لا تخلط بين إدخالات CCKM على تصحيح الأخطاء، ولا يتم إستخدام ذلك من أجل تنفيذ CCKM، بل OKC، كما هو موضح سابقا. CCKM هنا هو مجرد اسم مستخدم من قبل WLC لتلك المخرجات، مثل اسم دالة تتعامل مع القيم من أجل حساب PMKID.
ملاحظة: يمكن أن يعمل هذا الإعداد إذا لم تكن نقاط الوصول (APs) على مجموعة FlexConnect نفسها، ولكن هذا ليس إعداد مستحسن أو مدعوما.
يعرف التخزين المؤقت الاستباقي للمفتاح (أو PKC) باسم OKC (ذاكرة التخزين المؤقت للمفتاح الانتهازي)، ويتم إستخدام المصطلحين بالتبادل عندما يصفان نفس الطريقة الموضحة هنا. ومع ذلك، لم يكن هذا سوى مصطلح استخدمه المجال الجوي في عام 2001 لطريقة تخزين مؤقت قديمة للمفاتيح، والتي استخدمها بعد ذلك معيار 802.11i كأساس ل "مصادقة مسبقة" (وهو أسلوب آخر من أساليب التجوال السريع المأمون والموضحة أدناه بإيجاز). PKC ليس Preauthentication أو OKC (التخزين المؤقت للمفتاح الانتهازي)، ولكن عندما تسمع عن PKC أو تقرأ عنه، فإن المرجع هو أساسا إلى OKC، وليس إلى ما قبل المصادقة.
كما يتم اقتراح هذه الطريقة من قبل معيار IEEE 802.11 داخل تعديل الأمان 802.11i، لذلك فإنها تعمل أيضا مع WPA2، ولكنها الطريقة الوحيدة للتجوال الآمن السريع التي لا تدعمها البنية الأساسية لشبكة WLAN من Cisco. ولهذا السبب، لا يشرح إلا بإيجاز هنا وبدون نواتج.
باستخدام عملية ما قبل المصادقة، يمكن للعملاء اللاسلكي المصادقة باستخدام نقاط وصول متعددة في كل مرة أثناء اقترانها بنقطة الوصول الحالية. عندما يحدث ذلك، يرسل العميل إطارات مصادقة EAP إلى نقطة الوصول الحالية حيث تكون متصلة، ولكنها موجهة إلى نقطة (نقاط) الوصول الأخرى حيث يريد العميل إجراء المصادقة المسبقة (نقاط الوصول المجاورة التي يمكن ترشيحها للتجوال). ترسل نقطة الوصول الحالية هذه الإطارات إلى نقاط الوصول (AP) الهدف عبر نظام التوزيع. تقوم نقطة الوصول الجديدة بإجراء مصادقة كاملة مقابل خادم RADIUS لهذا العميل، لذلك يتم إكمال مصافحة مصادقة EAP جديدة بالكامل، وتعمل نقطة الوصول الجديدة هذه كمصدق.
تتمثل الفكرة في إجراء المصادقة واشتقاق PMK مع نقاط الوصول (APs) المجاورة قبل أن يقوم العميل بالفعل بالتجوال إليها، لذلك عندما يحين الوقت للتجول، تتم مصادقة العميل بالفعل وبوجود PMK مخزنا مؤقتا بالفعل لهذا الاقتران الآمن الجديد بين نقاط الوصول والعميل، لذلك لا يحتاجون إلا إلى إجراء المصافحة الرباعية الإتجاه والتجربة السريعة بعد أن يرسل العميل طلب إعادة الدمج الأولي الخاص به.
هنا صورة من منارة AP تظهر حقل RSN IE الذي يعلن عن دعم للمصادقة المسبقة (هذا واحد من نقطة وصول Cisco، حيث يتم التأكد من أن المصادقة المسبقة غير مدعومة):
هناك PMK واحد لكل اقتران آمن ل AP-to-client، والذي يمكن اعتباره ميزة أمان في حالة أختراق نقطة وصول وسرقة المفاتيح (لا يمكن إستخدامها مع نقاط وصول أخرى). ومع ذلك، يتم التعامل مع ميزة الأمان هذه بواسطة البنية الأساسية للشبكة المحلية اللاسلكية (WLAN) بطرق مختلفة على طرق أخرى.
تقنية التجوال السريع-الآمن القائمة على التعديل 802.11r (المسمى رسميا الانتقال السريع ل BSS حسب معيار 802.11، والمعروفة باسم FT) هي الطريقة الأولى التي تم التصديق عليها رسميا (في 2008) من قبل IEEE لمعيار 802.11 باعتباره الحل لإجراء عمليات انتقال سريعة بين نقاط الوصول (مجموعات الخدمات الأساسية أو وحدات BSS)، والذي يحدد بشكل واضح التسلسل الهرمي للمفتاح الذي يتم إستخدامه عند معالجة مفاتيح التخزين المؤقت على شبكة محلية لاسلكية (WLAN). ومع ذلك، كان اعتماده بطيئا، ويعزى ذلك أساسا إلى الحلول الأخرى المتاحة بالفعل عندما كانت هناك حاجة فعلية إلى عمليات انتقال سريعة، مثل عمليات تنفيذ شبكات VoWLAN عند إستخدامها مع إحدى الطرق الموضحة سابقا في هذا المستند. لا يوجد سوى عدد قليل من الأجهزة التي تدعم حاليا بعض خيارات ft (بحلول عام 2013).
هذا الأسلوب أكثر تعقيدا للشرح من الطرق الأخرى، حيث يقدم مفاهيم جديدة وطبقات متعددة من PMKs التي يتم تخزينها مؤقتا على أجهزة مختلفة (كل جهاز له دور مختلف)، ويوفر المزيد من الخيارات للتجوال الآمن بسرعة. لذلك، يتم توفير ملخص موجز عن هذه الطريقة والطريقة التي يتم بها تنفيذها مع كل خيار متاح.
يختلف معيار 802.11r عن معيار SKC ومعيار OKC، ويرجع ذلك في المقام الأول إلى الأسباب التالية:
باستخدام هذه الطريقة، يقوم العميل اللاسلكي بإجراء مصادقة أولية واحدة فقط مقابل البنية الأساسية للشبكة المحلية اللاسلكية (WLAN) عند تأسيس اتصال بنقطة الوصول الأولى، ويقوم بتنفيذ التجوال السريع الآمن أثناء التجوال بين نقاط الوصول من نفس مجال تنقل FT.
هذا هو أحد المفاهيم الجديدة، والتي تشير أساسا إلى نقاط الوصول التي تستخدم نفس SSID (المعروفة باسم مجموعة الخدمة الموسعة أو ESS) والتي تتعامل مع نفس مفاتيح FT. وهذا مماثل للأساليب الأخرى التي تم شرحها حتى الآن. عادة ما تستند الطريقة التي تتعامل بها نقاط الوصول مع مفاتيح مجال تنقل FT إلى إعداد مركزي، مثل مجموعة WLC أو مجموعات التنقل، ومع ذلك، يمكن تنفيذ هذه الطريقة أيضا على بيئات AP المستقلة.
فيما يلي ملخص للتسلسل الهرمي للمفاتيح:
ملاحظة: يمكن للبنية الأساسية للشبكة المحلية اللاسلكية (WLAN) نقل المفاتيح ومعالجتها بطريقة مختلفة، وذلك بناء على مورد الشبكة المحلية اللاسلكية (WLAN) وشرائح التنفيذ (مثل نقاط الوصول (AP) المستقلة أو FlexConnect أو Mesh). بل إنه يستطيع حتى تغيير أدوار حاملي المفاتيح، ولكن نظرا لأن ذلك خارج نطاق هذا المستند، فإن الأمثلة المستندة إلى ملخص التدرج الهرمي الرئيسي الذي تم تقديمه سابقا هي التركيز التالي. إن الاختلافات في الواقع ليست بتلك الأهمية لفهم العملية، ما لم تكن بحاجة بالفعل إلى التحليل التفصيلي لأجهزة البنية الأساسية (ورموزها) من أجل اكتشاف مشكلة في البرنامج.
باستخدام هذه الطريقة، يكون أول اقتران بأي نقطة وصول مصادقة منتظمة من المرة الأولى للشبكة المحلية اللاسلكية (WLAN)، حيث يجب أن تحدث مصادقة 802. 1X/EAP بالكامل مقابل خادم المصادقة ومصافحة 4 طرق لإنشاء المفاتيح قبل إرسال إطارات البيانات، كما هو موضح في صورة الشاشة هذه:
والاختلافات الرئيسية هي:
تظهر الأخطاء بشكل أساسي نفس تبادل إطار مصادقة EAP كباقي الطرق عند المصادقة الأولية للشبكة المحلية اللاسلكية (كما هو ملاحظ من الصور)، لكن تتم إضافة بعض المخرجات التي تتعلق بتقنيات التخزين المؤقت للمفتاح المستخدمة من قبل عنصر التحكم في الشبكة المحلية اللاسلكية (WLC)، وبالتالي، يتم قطع إخراج تصحيح الأخطاء هذا لعرض المعلومات ذات الصلة فقط:
*apfMsConnTask_0: Jun 27 19:25:23.426: ec:85:2f:15:39:32
Association received from mobile on BSSID
84:78:ac:f0:68:d6
!--- This is the Association request from the client.
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Marking this mobile as TGr capable.
!--- WLC recognizes that the client is 802.11r-capable.
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Processing RSN IE type 48, length 20 for mobile
ec:85:2f:15:39:32
!--- The WLC/AP finds an Information Element that claims FT
support on the Association request that is sent from the client.
*apfMsConnTask_0: Jun 27 19:25:23.427:
Sending assoc-resp station:ec:85:2f:15:39:32
AP:84:78:ac:f0:68:d0-00 thread:144be808
*apfMsConnTask_0: Jun 27 19:25:23.427:
Adding MDIE, ID is:0xaaf0
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Including FT Mobility Domain IE (length 5) in Initial
assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Sending R0KH-ID as:-84.30.6.-3
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Sending R1KH-ID as 3c:ce:73:d8:02:00
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Including FT IE (length 98) in Initial Assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:25:23.427: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d6
(status 0) ApVapId 7 Slot 0
!--- The Association Response is sent to the client once the
FT information is computed (as per the previous messages),
so this is included in the response.
*dot1xMsgTask: Jun 27 19:25:23.432: ec:85:2f:15:39:32
Sending EAP-Request/Identity to mobile ec:85:2f:15:39:32
(EAP Id 1)
!--- EAP begins, andfollows
the same exchange explained so far.
*apfMsConnTask_0: Jun 27 19:25:23.436: ec:85:2f:15:39:32
Got action frame from this client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.449: ec:85:2f:15:39:32
Received Identity Response (count=1) from mobile
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32
Processing Access-Challenge for mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.456: ec:85:2f:15:39:32
Sending EAP Request from AAA to mobile ec:85:2f:15:39:32
(EAP Id 2)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32
Received EAPOL EAPPKT from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.479: ec:85:2f:15:39:32
Received EAP Response from mobile ec:85:2f:15:39:32
(EAP Id 2, EAP Type 25)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Processing Access-Accept for mobile ec:85:2f:15:39:32
!--- The client is validated/authenticated by the RADIUS Server.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Creating a PKC PMKID Cache entry for station
ec:85:2f:15:39:32 (RSN 2)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Resetting MSCB PMK Cache Entry 0 for station
ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.627: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 0
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: ec:85:2f:15:39:32
Adding BSSID 84:78:ac:f0:68:d6 to PMKID cache at index 0
for station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628: New PMKID: (16)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.628:
[0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629: ec:85:2f:15:39:32
Created PMK Cache Entry for TGr AKM:802.1x ec:85:2f:15:39:32
!--- WLC creates a PMK cache entry for this client, which is
used for FT with 802.1X in this case, so the PMKID is
computed with the AP MAC address (BSSID 84:78:ac:f0:68:d6).
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.629:
ec:85:2f:15:39:32 R0KH-ID:172.30.6.253
R1KH-ID:3c:ce:73:d8:02:00 MSK Len:48 pmkValidTime:1807
!--- The R0KH-ID and R1KH-ID are defined, as well as the PMK
cache validity period.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
PMK sent to mobility group
!--- The FT PMK cache entry for this client is shared with the
WLCs on the mobility group.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Sending EAP-Success to mobile ec:85:2f:15:39:32 (EAP Id 12)
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d6 in PMKID
cache at index 0 of station ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: Including PMKID in
M1 (16)
!--- The hashed PMKID is included on the Message-1 of the
initial FT 4-Way handshake.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630:
[0000] 52 b8 8f cf 50 a7 90 98 2b ba d6 20 79 e4 cd f9
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.630: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
INITPMK (message 1), replay counter 00.00.00.00.00.00.00.0
!--- Message-1 of the FT 4-Way handshake is sent from the
WLC/AP to the client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from
mobile ec:85:2f:15:39:32
!--- Message-2 of the FT 4-Way handshake is received
successfully from the client.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Calculating PMKR0Name
!--- The PMKR0Name is calculated.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
DOT11R: Sending cache add
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: Adding MDIE,
ID is:0xaaf0
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Adding TIE for reassociation deadtime:20000 milliseconds
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.639: ec:85:2f:15:39:32
Adding TIE for R0Key-Data valid time :1807
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.640: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
!--- After the MDIE, TIE for reassociation deadtime, and TIE
for R0Key-Data valid time are calculated, the Message-3
of this FT 4-Way handshake is sent from the WLC/AP to the
client with this information.
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:25:23.651: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
!--- Message-4 (final message) of this initial FT 4-Way handshake
is received successfully from the client, which confirms the
installation of the derived keys. They can now be used in order
to encrypt data frames with the current AP.
ملاحظة: لتصحيح أخطاء هذه الطريقة والوصول إلى مخرجات 802.11r/ft الإضافية الموضحة هنا، يتم تمكين تصحيح أخطاء إضافي مع عميل تصحيح الأخطاء، وهو تمكين أحداث debug ft.
فيما يلي الصور وتصحيح أخطاء اقتران أولي بشبكة WLAN عند تنفيذ FT باستخدام WPA2-PSK (بدلا من طريقة 802.1X/EAP)، حيث يتم تحديد إطار إستجابة الاقتران من نقطة الوصول لعرض عنصر معلومات انتقال BSS السريع (مبرزة). كما يتم عرض بعض المعلومات الأساسية اللازمة لإجراء مصافحة FT 4-Way:
*apfMsConnTask_0: Jun 27 19:29:09.136: ec:85:2f:15:39:32
Association received from mobile on BSSID
84:78:ac:f0:68:d4
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Marking this mobile as TGr capable.
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Processing RSN IE type 48, length 20 for mobile
ec:85:2f:15:39:32
*apfMsConnTask_0: Jun 27 19:29:09.137: Sending assoc-resp
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:68:d0-00
thread:144be808
*apfMsConnTask_0: Jun 27 19:29:09.137: Adding MDIE,
ID is:0xaaf0
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Including FT Mobility Domain IE (length 5) in Initial
assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Sending R0KH-ID as:-84.30.6.-3
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Sending R1KH-ID as 3c:ce:73:d8:02:00
*apfMsConnTask_0: Jun 27 19:29:09.137: ec:85:2f:15:39:32
Including FT IE (length 98) in Initial Assoc Resp to mobile
*apfMsConnTask_0: Jun 27 19:29:09.138: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID 84:78:ac:f0:68:d4
(status 0) ApVapId 5 Slot 0
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Creating a PKC PMKID Cache entry for station
ec:85:2f:15:39:32 (RSN 2)
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Resetting MSCB PMK Cache Entry 0 for station
ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 8
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Setting active key cache index 8 ---> 0
*dot1xMsgTask: Jun 27 19:29:09.141: ec:85:2f:15:39:32
Adding BSSID 84:78:ac:f0:68:d4 to PMKID cache at
index 0 for station ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.142: New PMKID: (16)
*dot1xMsgTask: Jun 27 19:29:09.142:
[0000] 17 4b 17 5c ed 5f c7 1d 66 39 e9 5d 3a 63 69 e7
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Creating global PMK cache for this TGr client
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Created PMK Cache Entry for TGr AKM:PSK
ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
R0KH-ID:172.30.6.253 R1KH-ID:3c:ce:73:d8:02:00
MSK Len:48 pmkValidTime:1813
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Initiating RSN PSK to mobile ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.142: ec:85:2f:15:39:32
Found an cache entry for BSSID 84:78:ac:f0:68:d4 in
PMKID cache at index 0 of station ec:85:2f:15:39:32
*dot1xMsgTask: Jun 27 19:29:09.142: Including PMKID
in M1 (16)
*dot1xMsgTask: Jun 27 19:29:09.142:
[0000] 17 4b 17 5c ed 5f c7 1d 66 39 e9 5d 3a 63 69 e7
*dot1xMsgTask: Jun 27 19:29:09.143: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32
state INITPMK (message 1), replay counter
00.00.00.00.00.00.00.00
*apfMsConnTask_0: Jun 27 19:29:09.144: ec:85:2f:15:39:32
Got action frame from this client.
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.152: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Received EAPOL-key in PTK_START state (message 2) from
mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Calculating PMKR0Name
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: Adding MDIE,
ID is:0xaaf0
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Adding TIE for reassociation deadtime:20000 milliseconds
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.153: ec:85:2f:15:39:32
Adding TIE for R0Key-Data valid time :1813
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.154: ec:85:2f:15:39:32
Sending EAPOL-Key Message to mobile ec:85:2f:15:39:32 state
PTKINITNEGOTIATING (message 3), replay counter
00.00.00.00.00.00.00.01
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.163: ec:85:2f:15:39:32
Received EAPOL-Key from mobile ec:85:2f:15:39:32
*Dot1x_NW_MsgTask_2: Jun 27 19:29:09.163: ec:85:2f:15:39:32
Received EAPOL-key in PTKINITNEGOTIATING state (message 4)
from mobile ec:85:2f:15:39:32
باستخدام 802.11r، يكون الارتباط الأولي بالشبكة المحلية اللاسلكية (WLAN) هو الأساس المستخدم لاستخلاص المفاتيح الأساسية المستخدمة في هذا الأسلوب، تماما كما هو الحال في طرق التجوال الأخرى سريعة الأمان. وأهم الفروق هي عندما يبدأ العميل في التجوال، ولا يتجنب ft 802.1X/EAP فقط عند إستخدام ذلك، ولكنه ينفذ في الواقع طريقة تجوال أكثر فعالية تجمع بين إطارات 802.11 الأولية ل "مصادقة وإعادة تعيين النظام المفتوح" (والتي يتم إستخدامها ومتطلبها دائما عند التجوال بين نقاط الوصول) من أجل تبادل معلومات FT واستخلاص مفاتيح تشفير ديناميكية جديدة بدلا من المصافحة رباعية الإتجاه.
تظهر الصورة التالية الإطارات المتبادلة عند إجراء انتقال BSS سريع عبر الهواء مع أمان 802.1X/EAP. يتم تحديد إطار مصادقة النظام المفتوح من العميل إلى نقطة الوصول لترى عناصر معلومات بروتوكول FT المطلوبة لبدء تفاوض مفتاح FT. يتم إستخدام هذا الإجراء لاستخلاص PTK الجديد من نقطة الوصول الجديدة (استنادا إلى PMK-R1). يتم تمييز الحقل الذي يظهر خوارزمية المصادقة لإظهار أن هذا العميل لا يقوم بإجراء مصادقة نظام مفتوحة بسيطة، بل عملية انتقال سريعة ل BSS:
فيما يلي مخرجات تصحيح الأخطاء من عنصر التحكم في الشبكة المحلية اللاسلكية (WLC) عند حدوث حدث تجوال FT هذا مع 802.1X/EAP:
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
Doing preauth for this client over the Air
!--- WLC begins FT fast-secure roaming over-the-Air with
this client and performs a type of preauthentication,
because the client asks for this with FT on the Authentication
frame that is sent to the new AP over-the-Air
(before the Reassociation Request).
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
Doing local roaming for destination address
84:78:ac:f0:2a:96
!--- WLC performs the local roaming event with the new AP to
which the client roams.
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
Got 1 AKMs in RSNIE
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
RSNIE AKM matches with PMK cache entry :0x3
!--- WLC receives one PMK from this client (known as AKM here),
which matches the PMK cache entry hold for this client.
*apfMsConnTask_2: Jun 27 19:25:48.751: ec:85:2f:15:39:32
Created a new preauth entry for AP:84:78:ac:f0:2a:96
*apfMsConnTask_2: Jun 27 19:25:48.751: Adding MDIE,
ID is:0xaaf0
!--- WLC creates a new preauth entry for this AP-and-Client pair,
and adds the MDIE information.
*apfMsConnTask_2: Jun 27 19:25:48.763: Processing assoc-req
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
thread:144bef38
*apfMsConnTask_2: Jun 27 19:25:48.763: ec:85:2f:15:39:32
Reassociation received from mobile on BSSID
84:78:ac:f0:2a:96
!--- Once the client receives the Authentication frame reply from the
WLC/AP, the Reassociation request is sent, which is received at
the new AP to which the client roams.
*apfMsConnTask_2: Jun 27 19:25:48.764: ec:85:2f:15:39:32
Marking this mobile as TGr capable.
*apfMsConnTask_2: Jun 27 19:25:48.764: ec:85:2f:15:39:32
Processing RSN IE type 48, length 38 for mobile
ec:85:2f:15:39:32
*apfMsConnTask_2: Jun 27 19:25:48.765: ec:85:2f:15:39:32
Roaming succeed for this client.
!--- WLC confirms that the FT fast-secure roaming is successful
for this client.
*apfMsConnTask_2: Jun 27 19:25:48.765: Sending assoc-resp
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
thread:144bef38
*apfMsConnTask_2: Jun 27 19:25:48.766: Adding MDIE,
ID is:0xaaf0
*apfMsConnTask_2: Jun 27 19:25:48.766: ec:85:2f:15:39:32
Including FT Mobility Domain IE (length 5) in
reassociation assoc Resp to mobile
*apfMsConnTask_2: Jun 27 19:25:48.766: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID 84:78:ac:f0:2a:96
(status 0) ApVapId 7 Slot 0
!--- The Reassociation response is sent to the client, which
includes the FT Mobility Domain IE.
*dot1xMsgTask: Jun 27 19:25:48.769: ec:85:2f:15:39:32
Finishing FT roaming for mobile ec:85:2f:15:39:32
!--- FT roaming finishes and EAP is skipped (as well as any
other key management handshake), so the client is ready
to pass encrypted data frames with the current AP.
*dot1xMsgTask: Jun 27 19:25:48.769: ec:85:2f:15:39:32
Skipping EAP-Success to mobile ec:85:2f:15:39:32
فيما يلي صورة تعرض انتقالا سريعا ل BSS عبر الهواء مع أمان WPA2-PSK، حيث يتم تحديد إطار إستجابة إعادة التكوين النهائي من نقطة الوصول إلى العميل لإظهار مزيد من التفاصيل حول تبادل FT هذا:
فيما يلي مخرجات تصحيح الأخطاء عند حدوث حدث تجوال FT هذا مع PSK، والتي تكون مماثلة لتلك التي يتم فيها إستخدام 802.1X/EAP:
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
Doing preauth for this client over the Air
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
Doing local roaming for destination address
84:78:ac:f0:2a:94
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
Got 1 AKMs in RSNIE
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
RSNIE AKM matches with PMK cache entry :0x4
*apfMsConnTask_2: Jun 27 19:29:29.854: ec:85:2f:15:39:32
Created a new preauth entry for AP:84:78:ac:f0:2a:94
*apfMsConnTask_2: Jun 27 19:29:29.854: Adding MDIE,
ID is:0xaaf0
*apfMsConnTask_2: Jun 27 19:29:29.867: Processing assoc-req
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
thread:144bef38
*apfMsConnTask_2: Jun 27 19:29:29.867: ec:85:2f:15:39:32
Reassociation received from mobile on BSSID
84:78:ac:f0:2a:94
*apfMsConnTask_2: Jun 27 19:29:29.868: ec:85:2f:15:39:32
Marking this mobile as TGr capable.
*apfMsConnTask_2: Jun 27 19:29:29.868: ec:85:2f:15:39:32
Processing RSN IE type 48, length 38 for mobile
ec:85:2f:15:39:32
*apfMsConnTask_2: Jun 27 19:29:29.869: ec:85:2f:15:39:32
Roaming succeed for this client.
*apfMsConnTask_2: Jun 27 19:29:29.869: Sending assoc-resp
station:ec:85:2f:15:39:32 AP:84:78:ac:f0:2a:90-00
thread:144bef38
*apfMsConnTask_2: Jun 27 19:29:29.869: Adding MDIE,
ID is:0xaaf0
*apfMsConnTask_2: Jun 27 19:29:29.869: ec:85:2f:15:39:32
Including FT Mobility Domain IE (length 5) in
reassociation assoc Resp to mobile
*apfMsConnTask_2: Jun 27 19:29:29.870: ec:85:2f:15:39:32
Sending Assoc Response to station on BSSID
84:78:ac:f0:2a:94 (status 0) ApVapId 5 Slot 0
*dot1xMsgTask: Jun 27 19:29:29.874: ec:85:2f:15:39:32
Finishing FT roaming for mobile ec:85:2f:15:39:32
كما هو موضح في الصورة، بمجرد التفاوض على نقل BSS السريع بناء على الارتباط الأولي بالشبكة المحلية اللاسلكية (WLAN)، يتم إستخدام الإطارات الأربعة التي يتم إستخدامها وتطلبها للتجوال (مصادقة النظام المفتوح من العميل ومصادقة النظام المفتوحة من نقطة الوصول وطلب إعادة التعيين والاستجابة لإعادة التعيين) بشكل أساسي كمصافحة FT بأربع طرق من أجل اشتقاق PTK الجديد (مفتاح تشفير البث الأحادي) و GTK (مفتاح تشفير البث المتعدد/مفتاح تشفير البث).
يقوم هذا باستبدال مصافحة الأتجاه الأربعة التي تحدث عادة بعد تبادل هذه الإطارات، ويكون محتوى FT وتفاوض المفتاح على هذه الإطارات هو نفس ما إذا كنت تستخدم 802.1X/EAP أو PSK كطريقة تأمين. كما هو موضح في الصورة، فإن حقل AKM هو الاختلاف الرئيسي، والذي يؤكد ما إذا كان العميل يقوم بتنفيذ FT باستخدام PSK أو 802.1X. لذلك، من المهم ملاحظة أن هذه الإطارات الأربعة لا تحتوي عادة على هذا النوع من معلومات الأمان للتفاوض الأساسي، ولكن فقط عندما يقوم العميل بالتجوال إذا تم تنفيذ 802.11r والتفاوض بشأنها بين العميل والبنية الأساسية للشبكة المحلية اللاسلكية (WLAN) عند الاقتران الأولي.
802.11r يسمح بتنفيذ آخر للتحويل السريع BSS، حيث يبدأ العميل التجوال على الفك السفلي مع نقطة الوصول الجديدة التي يتجول العميل من أجلها عبر DS (نظام التوزيع)، وليس عبر الهواء. في هذه الحالة، يتم إستخدام إطارات إجراء FT لبدء التفاوض الرئيسي بدلا من إطارات مصادقة النظام المفتوحة.
في الأساس، عندما يقرر العميل أنه يمكنه التجوال إلى نقطة وصول أفضل، يرسل العميل إطار طلب إجراء FT إلى نقطة الوصول الأصلية حيث تكون متصلة حاليا قبل التجوال. يشير العميل إلى BSSID (عنوان MAC) لنقطة الوصول الهدف حيث يريد التجوال. تقوم نقطة الوصول الأصلية بإعادة توجيه إطار طلب إجراء FT هذا إلى نقطة الوصول الهدف عبر نظام التوزيع (عادة ما تكون البنية الأساسية السلكية)، وتستجيب نقطة الوصول الهدف إلى العميل من خلال إطار إستجابة إجراء FT (أيضا عبر DS، حتى يمكنها في النهاية إرسالها عبر الهواء إلى العميل). بمجرد نجاح تبادل إطار إجراء FT هذا، ينهي العميل تجوال FT؛ يرسل العميل طلب إعادة النشر إلى نقطة الوصول الهدف (هذه المرة عبر الهواء)، ويستلم إستجابة إعادة تعيين من نقطة الوصول الجديدة لتأكيد التجوال واشتقاق المفاتيح النهائية.
باختصار، هناك أربعة إطارات للتفاوض على انتقال BSS سريع واستخلاص مفاتيح تشفير جديدة، ولكن هنا يتم إستبدال إطارات مصادقة النظام المفتوح بإطارات طلب/إستجابة إجراء FT، والتي يتم تبادلها مع نقطة الوصول الهدف عبر نظام التوزيع مع نقطة الوصول الحالية. هذا الأسلوب صحيح أيضا لكل من طرق الأمان 802.1X/EAP و PSK، وكلها مدعومة من وحدات التحكم في شبكة LAN اللاسلكية من Cisco؛ ومع ذلك، بما أن هذا الانتقال عبر DS غير مدعوم ومنفذ من قبل معظم العملاء اللاسلكيين في صناعة WiFi (وبما أن مخرجات تبادل الإطارات وتصحيح الأخطاء هي نفسها أساسا)، فلا يتم توفير الأمثلة في هذا المستند. بدلا من ذلك، يتم إستخدام هذه الصورة لعرض الانتقال السريع ل BSS عبر-DS:
ومن أجل التغلب على هذه المشكلة، قدمت البنية الأساسية لشبكة LAN اللاسلكية من Cisco ميزة 802.11r المعدلة. عند تعيين وضع FT على Adaptive في مستوى الشبكة المحلية اللاسلكية (WLAN)، تعلن WLAN عن معرف مجال التنقل 802.11r على شبكة WLAN التي تم تمكين 802.11i بها. تحدد بعض أجهزة عميل Apple iOS10 وجود MDIE على شبكة محلية لاسلكية 80211i/WPA2 وتقوم بمصافحة خاصة من أجل إنشاء اقتران 802.11r. بمجرد أن يكمل العميل اقتران 802.11r الناجح، يمكنه القيام بالتجوال عبر الإنترنت كما هو الحال في شبكة WLAN العادية التي تم تمكين 802.11r بها. لا ينطبق مهايئ FT إلا على أجهزة Apple iOS10 (والإصدارات الأحدث) المحددة. يمكن لجميع العملاء الآخرين الاستمرار في الحصول على اقتران 802.11i/WPA2 على الشبكة المحلية اللاسلكية (WLAN)، وإجراء طريقة FSR القابلة للتطبيق كما هي مدعومة.
يمكن العثور على مزيد من الوثائق حول هذه الميزة الجديدة المقدمة لأجهزة iOS10 لإجراء 802.11r على شبكة WLAN/SSID حيث لم يتم تمكين 802.11r بشكل حقيقي (وبالتالي يمكن للعملاء الآخرين الذين ليسوا 802.11r الاتصال بنجاح) في أفضل ممارسات المؤسسات لأجهزة Cisco IOS على شبكة Cisco Wireless LAN.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
2.0 |
09-Feb-2023 |
الشكل المحدث والمعلومات التقنية التي تم التحقق منها. إعادة الاعتماد. |
1.0 |
02-Sep-2013 |
الإصدار الأولي |