تأكد من أساليب شبكة 802.11 المحلية اللاسلكية (WLAN) والتجوال السريع الآمن على Cuwn

المقدمة

يصف هذا المستند أنواع التجوال اللاسلكية والسريعة التأمين المتاحة لشبكات IEEE 802.11 المحلية اللاسلكية (WLANs) على الشبكة اللاسلكية الموحدة (CUWN).

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• المعيار IEEE 802.11 WLAN Fundamentals
• أمان IEEE 802.11 WLAN
• أساسيات IEEE 802.1x/EAP

المكونات المستخدمة

تستند المعلومات الواردة في هذا المستند إلى برنامج 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 في هذه الوثيقة:

• WPA/WPA2-PSK (مفتاح مشترك مسبقا) - مصادقة العملاء باستخدام مفتاح مشترك مسبقا.
• WPA/WPA2-EAP (بروتوكول المصادقة المتوسع) - مصادقة العملاء باستخدام طريقة 802. 1X/EAP للتحقق من بيانات الاعتماد الأكثر أمانا من خلال إستخدام خادم المصادقة، مثل الشهادات واسم المستخدم وكلمة المرور والرموز المميزة.

ومن المهم معرفة أنه على الرغم من أن هاتين الطريقتين (PSK و EAP) تثبتان/تحققان من صحة العملاء بطرق مختلفة، فإن كليهما يستخدم أساسا نفس قواعد WPA/WPA2 لعملية إدارة المفاتيح. سواء كان التأمين WPA/WPA2-PSK أو WPA/WPA2-EAP، فإن العملية المعروفة باسم WPA/WPA2 المصافحة رباعية الإتجاه تبدأ التفاوض الرئيسي بين WLC/AP والعميل بمفتاح جلسة رئيسي (MSK) كمادة أساسية أصلية بمجرد أن يتم التحقق من صحة العميل باستخدام طريقة مصادقة محددة مستخدمة.

فيما يلي ملخص للعملية:

1. يشتق MSK من مرحلة مصادقة EAP عند إستخدام تأمين 802.1X/EAP، أو من PSK عند إستخدام WPA/WPA2-PSK كطريقة تأمين.
2. من خلال MSK هذا، يستخرج العميل و WLC/AP المفتاح الرئيسي غير الحكيم (PMK)، وتقوم WLC/AP بإنشاء مفتاح رئيسي للمجموعة (GMK).
3. بمجرد أن يكون هذان المفتاحان الأساسيان جاهزين، يبدأ العميل و WLC/AP مصافحة WPA/WPA2 4-way (والتي يتم توضيحها لاحقا في هذا المستند مع بعض صور الشاشة وتصحيح الأخطاء) مع المفاتيح الأساسية كبذور للتفاوض على مفاتيح التشفير الحقيقية.
4. ومفاتيح التشفير النهائية هذه تعرف باسم مفتاح Pairwise المؤقت (PTK) ومفتاح المجموعة المؤقت (GTK). يتم اشتقاق PTK من PMK ويتم إستخدامه لتشفير إطارات البث الأحادي مع العميل. يتم اشتقاق مفتاح المجموعة المؤقت (GTK) من GMK، ويتم إستخدامه لتشفير البث/البث المتعدد على SSID/AP المحدد هذا.

WPA/WPA2-PSK

عند إجراء 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 من أجل اشتقاق مفاتيح تشفير جديدة مع نقطة الوصول الجديدة. ويرجع ذلك إلى الأسباب الأمنية التي أرساها المعيار، وإلى أن نقطة الوصول الجديدة لا تعرف المفاتيح الأصلية. الفرق الوحيد هو أن هناك إطارات إعادة تشكيل بدلا من إطارات الاقتران، كما هو موضح في هذه الصورة:

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

WPA/WPA2-EAP

عند إستخدام طريقة 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 into Connecting 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، في القسم التالي.

التجوال الآمن السريع مع CCKM

إدارة المفاتيح المركزية من 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).

FlexConnect مع CCKM

• المصادقة المركزية مدعومة. ويتضمن ذلك تبديل البيانات المحلية والمركزية. يجب أن تكون نقاط الوصول جزءا من مجموعة FlexConnect نفسها.
• المصادقة المحلية المرنة مدعومة. في الوضع المتصل، يمكن توزيع ذاكرة التخزين المؤقت من نقطة الوصول إلى وحدة التحكم ثم إلى باقي نقاط الوصول في مجموعة FlexConnect.
• الوضع المستقل مدعوم. إذا كانت ذاكرة التخزين المؤقت موجودة بالفعل على نقطة الوصول (بسبب التوزيع السابق)، يجب أن تعمل التجوال السريع. لا تدعم المصادقة الجديدة في الوضع المستقل التجوال السريع الآمن.

مزايا مع CCKM

• CCKM هو أسرع طريقة تجوال سريعة الأمان يتم نشرها غالبا على شبكات WLAN الخاصة بالمؤسسات. لا يحتاج العملاء إلى تمرير مصافحة إدارة مفاتيح لاستخلاص مفاتيح جديدة عندما يحدث انتقال بين نقاط الوصول، ولا يطلب منهم مرة أخرى إجراء مصادقة 802.1X/EAP كاملة باستخدام نقاط وصول جديدة خلال العمر الافتراضي للعميل على شبكة WLAN هذه.
• يدعم CCKM جميع طرق التشفير المتاحة في معيار 802.11 (WEP، TKIP، و AES)، بالإضافة إلى بعض أساليب Cisco الخاصة القديمة والتي لا تزال تستخدم على العملاء القدامى.

مخاريط مع CCKM

• CCKM هو أسلوب خاص من Cisco، والذي يحد من التنفيذ والدعم لبنية Cisco WLAN الأساسية وعملاء CCX اللاسلكي.
• لم يتم اعتماد CCX الإصدار 5 على نطاق واسع، لذلك فإن CCKM مع WPA2/AES غير مدعوم من قبل العديد من عملاء CCX اللاسلكيين (ويرجع ذلك أساسا إلى أن معظمهم يدعمون CCKM بالفعل مع WPA/TKIP، والتي لا تزال آمنة جدا).

التجوال السريع الآمن باستخدام ذاكرة التخزين المؤقت للمفاتيح/التخزين المؤقت للمفاتيح اللاصقة

يعتبر التخزين المؤقت لمعرف Key (PMKID) أو التخزين المؤقت للمفاتيح اللاصقة (SKC) أول طريقة تجوال سريعة التأمين يقترحها معيار IEEE 802.11 في تعديل الأمان 802.11i، حيث يكون الغرض الرئيسي هو توحيد مستوى عال من الأمان لشبكات WLAN. تمت إضافة تقنية التجوال السريع التأمين هذه كطريقة إختيارية لأجهزة WPA2 من أجل تحسين التجوال عند تنفيذ هذا التأمين.

وهذا ممكن لأنه في كل مرة تتم مصادقة العميل بالكامل على EAP، يستمد العميل وخادم المصادقة MSK، والذي يتم إستخدامه لاستخلاص PMK. يستخدم هذا كبذرة لمصافحة WPA2 4-Way لاستخلاص مفتاح تشفير البث الأحادي النهائي (PTK) الذي يتم إستخدامه للجلسة (حتى يجول العميل إلى نقطة وصول أخرى أو تنتهي الجلسة)، ومن ثم، تمنع هذه الطريقة مرحلة مصادقة EAP عند التجوال لأنه يعيد إستخدام PMK الأصلي الذي تم تخزينه مؤقتا من قبل العميل و AP. يجب على العميل فقط إجراء تأكيد الاتصال رباعي الإتجاه WPA2 من أجل اشتقاق مفاتيح تشفير جديدة.

لا يتم نشر هذه الطريقة على نطاق واسع نظرا لطريقة التجوال القياسية الآمنة 802.11 الموصى بها ويرجع ذلك بشكل أساسي إلى هذه الأسباب:

• هذه الطريقة إختيارية ولا تدعمها جميع أجهزة WPA2، لأن الغرض من تعديل 802.11i لا يتعلق بالتجوال السريع والآمن، وقد عمل IEEE بالفعل على تعديل آخر لتوحيد التجوال السريع والآمن لشبكات WLAN (802.11r، والذي تتم تغطيته لاحقا في هذا المستند).
• تفرض هذه الطريقة قيودا كبيرة على تنفيذها: لا يمكن للعملاء اللاسلكيين إجراء التجوال المؤمن بسرعة إلا عند التجوال مرة أخرى إلى نقطة وصول حيث سبق لهم التصديق/الاتصال.

باستخدام هذه الطريقة، يكون الاقتران الأولي بأي نقطة وصول بمثابة مصادقة عادية لأول مرة للشبكة المحلية اللاسلكية (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

FlexConnect مع ذاكرة التخزين المؤقت ل PMKID / ذاكرة التخزين المؤقت للمفاتيح اللاصقة

• عند إستخدام هذه الطريقة على إعداد FlexConnect، قد تعمل وقد يبدو السلوك مماثلا لما تم شرحه سابقا إذا قمت باستخدام المصادقة المركزية مرة أخرى إلى عنصر التحكم في الشبكة المحلية اللاسلكية (WLC) (باستخدام التحويل المركزي أو المحلي)، ومع ذلك، لا يتم دعم طريقة SKC هذه على FlexConnect.
• هذا أسلوب فقط معتمد رسميا على CUWN مع أسلوب APs محلي، ليس على FlexConnect أو آخر أسلوب.

PROS مع ذاكرة التخزين المؤقت ل PMKID / ذاكرة التخزين المؤقت للمفاتيح اللاصقة 

يمكن تنفيذ هذه الطريقة محليا بواسطة نقاط الوصول (AP) المستقلة، دون الحاجة إلى جهاز مركزي لإدارة المفاتيح المخزنة مؤقتا.

مخالط مع ذاكرة التخزين المؤقت ل PMKID / ذاكرة التخزين المؤقت للمفاتيح اللاصقة

• وكما تمت الإشارة إليه مسبقا في هذا المستند، يتمثل الحد الرئيسي لهذه الطريقة في أنه لا يمكن للعميل إجراء التجوال الآمن السريع إلا عند التجوال مرة أخرى إلى نقطة وصول حيث كانت مقترنة/مصدق عليها مسبقا. في حالة التجوال إلى نقطة وصول جديدة، يجب على العميل إكمال مصادقة EAP الكاملة مرة أخرى.
• يجب أن يتذكر العميل اللاسلكي و APs كل PMKs المشتقة من كل مصادقة جديدة، لذلك فهذه الميزة تقتصر عادة على مقدار معين من PMKs التي يتم تخزينها مؤقتا. ونظرا لأن هذا الحد غير محدد بوضوح بواسطة المعيار، فيمكن للموردين تحديد حدود مختلفة على عمليات تنفيذ SKC الخاصة بهم. على سبيل المثال، يمكن لوحدات التحكم في الشبكة المحلية اللاسلكية (WLAN) من Cisco حاليا تخزين وحدات التحكم في الشبكة المحلية اللاسلكية (PMK) مؤقتا من عميل لما يصل إلى ثماني نقاط وصول (APs). إن يجول زبون إلى أكثر من ثمانية APs لكل جلسة، أزلت الأقدم APs من التخزين المؤقت قائمة in order to خزنت الإدخالات حديثا.
• هذه الطريقة إختيارية ولا تزال غير معتمدة من قبل العديد من أجهزة WPA2، وبالتالي، فإن هذه الطريقة غير معتمدة ولا يتم نشرها على نطاق واسع.
• لا يتم دعم SKC عند إجراء التجوال بين وحدات التحكم البينية، والذي يحدث عند النقل بين نقاط الوصول التي تتم إدارتها بواسطة وحدات تحكم الشبكة المحلية اللاسلكية (WLC) مختلفة، حتى إذا كانت على نفس مجموعة التنقل.

  

التجوال السريع الآمن مع التخزين المؤقت للمفتاح الانتهازي

إن التخزين المؤقت الانتهازي للمفتاح (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.

FlexConnect مع التخزين المؤقت للمفتاح الانتهازي

• المصادقة المركزية مدعومة. ويتضمن ذلك تبديل البيانات المحلية والمركزية. إذا كانت نقطة الوصول جزءا من مجموعة FlexConnect نفسها، فإن التجوال سريع الأمان يتم بواسطة نقطة الوصول، وإلا فإن التجوال سريع الأمان يتم بواسطة وحدة التحكم.
  

  ملاحظة: يمكن أن يعمل هذا الإعداد إذا لم تكن نقاط الوصول (APs) على مجموعة FlexConnect نفسها، ولكن هذا ليس إعداد مستحسن أو مدعوما.

• المصادقة المحلية المرنة مدعومة. في الوضع المتصل، يمكن توزيع ذاكرة التخزين المؤقت من نقطة الوصول إلى وحدة التحكم ثم إلى باقي نقاط الوصول في مجموعة FlexConnect. 
• الوضع المستقل مدعوم. إذا كانت ذاكرة التخزين المؤقت موجودة بالفعل على نقطة الوصول (نظرا للتوزيع السابق)، يجب أن تعمل التجوال السريع الآمن. لا تدعم المصادقة الجديدة في الوضع المستقل التجوال السريع الآمن.

PROS مع ذاكرة التخزين المؤقت للمفتاح الانتهازي

• لا يحتاج العميل اللاسلكي والبنية الأساسية للشبكة المحلية اللاسلكية (WLAN) إلى تذكر العديد من PMKIDs، بل ببساطة تخزين PMK الأصلي الواحد مؤقتا من المصادقة الأولية إلى الشبكة المحلية اللاسلكية (WLAN). بعد ذلك يجب إعادة تجزئة PMKID المناسب (المستخدم في طلب إعادة التعيين) المطلوب مع كل اقتران آمن لنقطة الوصول للتحقق من صحة التجوال السريع الآمن.
• هنا يقوم العميل اللاسلكي بالتجوال السريع والآمن إلى نقطة وصول جديدة على نفس شبكة WLAN/SSID، حتى وإن لم تكن مقترنة أبدا بنقطة الوصول تلك (وليس الحالة في SKC). طالما يقوم العميل بتنفيذ المصادقة الأولية ل 802.1X/EAP باستخدام نقطة وصول واحدة تتم إدارتها بواسطة النشر المركزي الذي يعالج ذاكرة التخزين المؤقت ل PMK لجميع نقاط الوصول حيث يتجول العميل، فلن تكون هناك أي مصادقة كاملة أخرى مطلوبة لباقي فترة بقاء العميل على شبكة WLAN هذه.

CONS مع التخزين المؤقت للمفتاح الانتهازي

• يتم نشر هذه الطريقة فقط على بيئة مركزية حيث تكون جميع نقاط الوصول تحت نوع ما من التحكم الإداري (مثل وحدة التحكم في الشبكة المحلية اللاسلكية (WLAN) المسؤولة عن التخزين المؤقت لذاكرة PMK الأصلية الواحدة ومشاركتها من جلسة عمل العميل. لذلك، هذا تقييد على بيئات AP المستقلة.
• والتقنيات التي يتم تطبيقها في هذه الطريقة غير مقترحة أو موصوفة في معيار 802.11، لذلك يختلف الدعم بشكل كبير من جهاز إلى آخر. ومع ذلك، لا تزال هذه هي الطريقة التي تم اعتمادها بشكل أكبر في انتظار الإصدار 802.11r.

ملاحظة حول مصطلح "التخزين المؤقت الاستباقي للمفاتيح"

يعرف التخزين المؤقت الاستباقي للمفتاح (أو 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، حيث يتم التأكد من أن المصادقة المسبقة غير مدعومة):

PROS مع ما قبل المصادقة

هناك PMK واحد لكل اقتران آمن ل AP-to-client، والذي يمكن اعتباره ميزة أمان في حالة أختراق نقطة وصول وسرقة المفاتيح (لا يمكن إستخدامها مع نقاط وصول أخرى). ومع ذلك، يتم التعامل مع ميزة الأمان هذه بواسطة البنية الأساسية للشبكة المحلية اللاسلكية (WLAN) بطرق مختلفة على طرق أخرى.

مخالط مع ما قبل المصادقة

• بسبب وجود PMK واحد لكل نقطة وصول، يكون للعملاء حد على مقدار نقاط الوصول التي يمكن مصادقتها مسبقا.
• في كل مرة يقوم فيها العميل بإجراء مصادقة مسبقة مع نقطة وصول جديدة، يكون هناك تبادل مصادقة EAP كامل، ما يعني المزيد من التحميل على الشبكة وعلى خادم المصادقة.
• لا يساند معظم الزبائن اللاسلكيين هذه الطريقة، لأنها لم تكن أبدا معتمدة بشكل عال (كانت OKC معتمدة بشكل أكبر).

التجوال السريع الآمن مع 802.11r

تقنية التجوال السريع-الآمن القائمة على التعديل 802.11r (المسمى رسميا الانتقال السريع ل BSS حسب معيار 802.11، والمعروفة باسم FT) هي الطريقة الأولى التي تم التصديق عليها رسميا (في 2008) من قبل IEEE لمعيار 802.11 باعتباره الحل لإجراء عمليات انتقال سريعة بين نقاط الوصول (مجموعات الخدمات الأساسية أو وحدات BSS)، والذي يحدد بشكل واضح التسلسل الهرمي للمفتاح الذي يتم إستخدامه عند معالجة مفاتيح التخزين المؤقت على شبكة محلية لاسلكية (WLAN). ومع ذلك، كان اعتماده بطيئا، ويعزى ذلك أساسا إلى الحلول الأخرى المتاحة بالفعل عندما كانت هناك حاجة فعلية إلى عمليات انتقال سريعة، مثل عمليات تنفيذ شبكات VoWLAN عند إستخدامها مع إحدى الطرق الموضحة سابقا في هذا المستند. لا يوجد سوى عدد قليل من الأجهزة التي تدعم حاليا بعض خيارات ft (بحلول عام 2013).

هذا الأسلوب أكثر تعقيدا للشرح من الطرق الأخرى، حيث يقدم مفاهيم جديدة وطبقات متعددة من PMKs التي يتم تخزينها مؤقتا على أجهزة مختلفة (كل جهاز له دور مختلف)، ويوفر المزيد من الخيارات للتجوال الآمن بسرعة. لذلك، يتم توفير ملخص موجز عن هذه الطريقة والطريقة التي يتم بها تنفيذها مع كل خيار متاح.

يختلف معيار 802.11r عن معيار SKC ومعيار OKC، ويرجع ذلك في المقام الأول إلى الأسباب التالية:

• تحدث رسائل المصافحة (PMKID، ANonce، و SNonce exchange، على سبيل المثال) في إطارات مصادقة 802.11 أو في إطارات إجراء بدلا من إطارات إعادة التعيين. على عكس أساليب ذاكرة التخزين المؤقت ل PMKID، يتم تجنب مرحلة المصافحة المنفصلة رباعية الإتجاه، والتي يتم نقلها بعد تبادل رسائل (إعادة)الاقتران. تبدأ مصافحة المفتاح مع نقطة الوصول الجديدة قبل أن يقوم العميل بالتجوال/إعادة التئام مع نقطة الوصول الجديدة هذه.
• يوفر طريقتين للمصافحة سريعة التجوال: عبر الهواء ونظام التوزيع (DS).
• يحتوي 802.11r على المزيد من طبقات هيكل المفاتيح.
• بما أن هذا البروتوكول يتجنب المصافحة رباعية الإتجاه لإدارة المفاتيح عندما يجول العميل (ويولد مفاتيح تشفير جديدة -PTK و GTK- دون حاجة إلى هذه المصافحة)، يمكن أيضا تطبيقها على إختبارات WPA2 مع PSK، وليس فقط عندما يتم إستخدام 802.1X/EAP للمصادقة. يسرع هذا من التجوال أكثر لهذه التجهيزات حيث لا يوجد EAP أو المصافحة الرباعية.

باستخدام هذه الطريقة، يقوم العميل اللاسلكي بإجراء مصادقة أولية واحدة فقط مقابل البنية الأساسية للشبكة المحلية اللاسلكية (WLAN) عند تأسيس اتصال بنقطة الوصول الأولى، ويقوم بتنفيذ التجوال السريع الآمن أثناء التجوال بين نقاط الوصول من نفس مجال تنقل FT.

هذا هو أحد المفاهيم الجديدة، والتي تشير أساسا إلى نقاط الوصول التي تستخدم نفس SSID (المعروفة باسم مجموعة الخدمة الموسعة أو ESS) والتي تتعامل مع نفس مفاتيح FT. وهذا مماثل للأساليب الأخرى التي تم شرحها حتى الآن. عادة ما تستند الطريقة التي تتعامل بها نقاط الوصول مع مفاتيح مجال تنقل FT إلى إعداد مركزي، مثل مجموعة WLC أو مجموعات التنقل، ومع ذلك، يمكن تنفيذ هذه الطريقة أيضا على بيئات AP المستقلة.

فيما يلي ملخص للتسلسل الهرمي للمفاتيح:

• لا يزال MSK مشتقا على طالب العميل وخادم المصادقة من مرحلة مصادقة 802.1X/EAP الأولية (يتم تحويلها من خادم المصادقة إلى المصدق (WLC) بمجرد نجاح المصادقة). يتم إستخدام MSK هذا، مثل الطرق الأخرى، كبذرة للتدرج الهرمي لمفتاح FT. عندما تستخدم WPA2-PSK بدلا من أسلوب مصادقة EAP، فإن PSK يكون في الأساس هذا MSK.
• يتم اشتقاق مفتاح R0 رئيسي رئيسي غير حكيم (PMK-R0) من MSK، والذي هو مفتاح المستوى الأول من التسلسل الهرمي لمفتاح FT. أصحاب المفاتيح لهذا PMK-R0 هم WLC والعميل.
• يتم اشتقاق مفتاح المستوى الثاني، يسمى مفتاح R1 الرئيسي Pairwise (PMK-R1)، من PMK-R0، وحملة المفاتيح هم العميل ونقاط الوصول التي تديرها WLC التي تحمل PMK-R0.
• مفتاح المستوى الثالث والأخير للتدرج الهرمي لمفتاح FT هو PTK، والذي هو المفتاح النهائي المستخدم لتشفير إطارات بيانات البث الأحادي 802.11 (مماثلة للأساليب الأخرى التي تستخدم WPA/TKIP أو WPA2/AES). يتم اشتقاق PTK هذا على FT من PMK-R1، وحاملو المفاتيح هم العميل ونقاط الوصول التي تديرها WLC.

ملاحظة: يمكن للبنية الأساسية للشبكة المحلية اللاسلكية (WLAN) نقل المفاتيح ومعالجتها بطريقة مختلفة، وذلك بناء على مورد الشبكة المحلية اللاسلكية (WLAN) وشرائح التنفيذ (مثل نقاط الوصول (AP) المستقلة أو FlexConnect أو Mesh). بل إنه يستطيع حتى تغيير أدوار حاملي المفاتيح، ولكن نظرا لأن ذلك خارج نطاق هذا المستند، فإن الأمثلة المستندة إلى ملخص التدرج الهرمي الرئيسي الذي تم تقديمه سابقا هي التركيز التالي. إن الاختلافات في الواقع ليست بتلك الأهمية لفهم العملية، ما لم تكن بحاجة بالفعل إلى التحليل التفصيلي لأجهزة البنية الأساسية (ورموزها) من أجل اكتشاف مشكلة في البرنامج.

انتقال BSS السريع عبر الهواء

باستخدام هذه الطريقة، يكون أول اقتران بأي نقطة وصول مصادقة منتظمة من المرة الأولى للشبكة المحلية اللاسلكية (WLAN)، حيث يجب أن تحدث مصادقة 802. 1X/EAP بالكامل مقابل خادم المصادقة ومصافحة 4 طرق لإنشاء المفاتيح قبل إرسال إطارات البيانات، كما هو موضح في صورة الشاشة هذه:

والاختلافات الرئيسية هي:

• يختلف تفاوض إدارة مفتاح المصادقة إختلافا طفيفا عن تفاوض WPA/WPA2 العادي، لذلك يتم إستخدام بعض المعلومات الإضافية لإجراء هذا التفاوض عند حدوث اقتران ببنية أساسية لشبكة WLAN تدعم ft. كما هو موضح في الصورة، يتم تحديد إطار طلب الاقتران من العميل ويتم تمييز حقل AKM الخاص بعنصر معلومات RNS لإظهار أن هذا العميل يريد تنفيذ FT أكثر من 802.1X/EAP.
• كما يظهر عنصر معلومات مجال التنقل (جزء من FT)، حيث يشير حقل قدرة FT والسياسة إلى ما إذا كان الانتقال السريع ل BSS مكتملا عبر الهواء أو عبر DS عند التجوال السريع (يشير ذلك إلى ما هو عبر الهواء في هذه الصورة).
• كما تتم إضافة عنصر معلومات آخر (نقل BSS السريع أو FT IE، والموضحة لاحقا في هذا المستند) مع المعلومات المطلوبة لتنفيذ تسلسل مصادقة FT عند تجوال FT.
• يختلف جيل المفاتيح باختلاف التسلسل الهرمي للمفاتيح، لذلك على الرغم من أن المصافحة FT 4-way تبدو مشابهة للمصافحة WPA/WPA2 4-Way، إلا أنها في الواقع تختلف قليلا في المحتوى.

تظهر الأخطاء بشكل أساسي نفس تبادل إطار مصادقة 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, and follows 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) عند الاقتران الأولي.

انتقال BSS السريع عبر DS

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:

تقنية FlexConnect مع الطراز 802.11r

• المصادقة المركزية مدعومة. ويتضمن ذلك تبديل البيانات المحلية والمركزية. يجب أن تكون نقاط الوصول جزءا من مجموعة FlexConnect نفسها.
• المصادقة المحلية غير مدعومة.
• الوضع المستقل غير مدعوم.

ميزات مع 802.11r

• هذه الطريقة هي الأولى التي تستخدم تراتبا هرميا رئيسيا تم تعريفه بشكل واضح بواسطة IEEE على مقياس 802.11 كتعديل (802.11r)، لذلك فإن تنفيذ تقنيات ft هذه يكون أكثر توافقا بين الموردين ودون تأويلات مختلفة.
• 802.11R تقنيات متعددة مفيدة تعتمد على إحتياجاتك (عبر الهواء وعبر نظام ds وأمان 802.1x/EAP وأمان PSK).
• يقوم العميل اللاسلكي بتنفيذ التجوال السريع الآمن إلى نقطة وصول جديدة على الشبكة المحلية اللاسلكية (WLAN)/SSID نفسها، حتى ولو لم تكن مقترنة بنقطة الوصول تلك مطلقا، دون الحاجة إلى حفظ العديد من بروتوكولات PMKID.
• هذه هي أول طريقة تجوال سريعة التأمين تتيح التجوال بسرعة أكبر حتى مع تأمين PSK، وتتجنب المصافحة الرباعية الإتجاه المطلوبة عند التجوال بين نقاط الوصول باستخدام WPA/WPA2 PSK. الغرض الأساسي من طرق التجوال السريعة التأمين هو تجنب مصافحة 802.1X/EAP عند تطبيق طريقة الأمان هذه، ومع ذلك، لأمان PSK يتم تسريع حدث التجوال أكثر مع 802.11r عند تجنب المصافحة الرباعية الإتجاه.

CONS مع 802.11r

• هناك عدد قليل من أجهزة العميل اللاسلكية التي تدعم بالفعل عمليات الانتقال السريعة ل BSS، وفي معظم الحالات، لا تدعم جميع التقنيات المتوفرة على معيار 802.11r.
• نظرا لحقيقة أن عمليات التنفيذ هذه صغيرة جدا، لا توجد نتائج إختبار كافية من بيئات الإنتاج الحقيقي أو نتائج تصحيح أخطاء كافية لمعالجة التنبيهات المحتملة التي يمكن أن تظهر.
• عندما تقوم بتكوين شبكة WLAN/SSID لاستخدام أي من طرق FT، يمكن فقط للعملاء اللاسلكي الذين يدعمون معيار 802.11r الاتصال بشبكة WLAN/SSID هذه. إعدادات FT ليست إختيارية للعملاء، لذا يجب على العملاء اللاسلكيين الذين لا يؤيدون معيار 802.11r الاتصال بشبكة محلية لاسلكية (WLAN)/SSID منفصلة حيث لم يتم تكوين FT على الإطلاق.

Adaptive 802.11r

• يتعذر على بعض العملاء القدامى الاقتران بشبكة WLAN/SSID التي تم تمكين 802.11r لها حتى في "الوضع المختلط" (والذي تأمل أن يكون لديك على نفس عملاء SSID الذين يدعمون ولا يدعمون 802.11r). يحدث ذلك عندما يكون برنامج تشغيل ملتمس العميل المسؤول عن تحليل عنصر معلومات شبكة الأمان القوي (RSN IE) قديما ولا يعرف مجموعات AKM الإضافية في IE. ونظرا لهذا التحديد، لا يمكن للعملاء إرسال طلبات الاقتران إلى شبكات WLAN التي تعلن عن دعم 802.11r، ومن ثم، تحتاج إلى تكوين شبكة WLAN/SSID واحدة لعملاء 802.11r وشبكة WLAN/SSID منفصلة للعملاء الذين لا تدعم شبكة 802.11r.

• ومن أجل التغلب على هذه المشكلة، قدمت البنية الأساسية لشبكة 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.

الخلاصة

• تذكر دائما أن العميل هو الذي يقرر التجوال إلى نقطة وصول معينة، ولا يمكن أن يقرر عنصر التحكم في الشبكة المحلية اللاسلكية (WLC)/نقطة الوصول هذا للعميل. يتم بدء حدث التجوال من قبل العميل اللاسلكي بمجرد أن يعتبر أنه يجب عليه التجوال.
• تدعم عنصر التحكم في الشبكة المحلية اللاسلكية (WLC) الجمع بين معظم أو جميع طرق FSR (التجوال السريع الآمن) معا على نفس شبكة WLAN/SSID. ومع ذلك، كن على علم بأن هذا لا يعمل عادة، حيث إنه يعتمد بشكل كبير على سلوك العميل (مختلف جدا عبر الأجهزة المحمولة المختلفة) من أجل دعم أو حتى فهم ما تحاول وحدة التحكم في الشبكة المحلية اللاسلكية (WLC) الإعلان عنه كمدعوم. وبدلا من تحقيق قابلية التشغيل البيني في معرف SSID واحد فقط، يكون هناك عادة عدد من المشاكل أكبر من تلك المتوقع إصلاحها، وبالتالي لا يوصى بذلك. يجب إكمال الاختبار العميق مع جميع العملاء المحتملين الذين سيتم إستخدامهم على شبكة WLAN هذه إذا كانت هناك حاجة فعلية لذلك.
• من المهم جدا أن تفهم أنه يتم تطوير طرق التجوال الآمنة بسرعة من أجل تسريع عملية التجوال على الشبكة المحلية اللاسلكية (WLAN) عندما تنتقل بين نقاط الوصول إذا كان هناك تأمين ممكن للشبكة المحلية اللاسلكية (WLAN)/SSID. في حالة عدم وجود تأمين، لا يوجد شيء للتعجيل، حيث تقوم نقطة الوصول بتبديل إطارات الإدارة اللاسلكية المطلوبة دائما عند التجوال بين نقاط الوصول قبل إرسال إطارات البيانات (مصادقة نظام مفتوحة من العميل ومصادقة نظام مفتوحة من نقطة الوصول وطلب إعادة الدمج والاستجابة لإعادة التعيين). لذلك، لا يمكن أن يتحرك هذا بشكل أسرع. إذا واجهت مشاكل تجوال بدون تأمين، فلا توجد طرق تجوال سريع لتحسين التجوال، فقط طرق للتأكد مما إذا كان إعداد وتصميم WLAN/SSID ملائمين لمحطات العملاء اللاسلكية للتنقل بالتبعية بين خلايا تغطية نقطة الوصول.
• يتم تنفيذ 802.11r/ft مع WPA2-PSK من أجل تسريع أحداث التجوال بهذا التأمين وتجنب المصافحة الرباعية الإتجاه، كما هو موضح ضمن قسم 802.11r.
• ولكل من الطرق مزاياها وعيوبها، ولكن في النهاية، يجب عليك التحقق دائما مما إذا كانت محطات العميل اللاسلكية تدعم الطريقة المحددة التي تريد تنفيذها، وما إذا كانت البنية الأساسية للشبكة المحلية اللاسلكية (WLAN) من Cisco تدعم جميع الطرق المتاحة. ومن ثم، يجب عليك تحديد أفضل الطرق التي يدعمها العملاء اللاسلكيون بالفعل والتي تتصل بالشبكة المحلية اللاسلكية (WLAN)/SSID المحددة. على سبيل المثال، في بعض عمليات النشر، يمكنك إنشاء شبكة WLAN/SSID باستخدام CCKM لهواتف Cisco Wireless IP (التي تدعم WPA2/AES باستخدام CCKM، ولكن ليس 802.11r)، ثم شبكة WLAN/SSID أخرى مع WPA2/AES عبر 802.11r/FT للعملاء اللاسلكيين الذين يدعمون طريقة التجوال السريع الآمن (أو يستخدمون OKC، إذا كان هذا ما يتم دعمه).
• إذا لم يدعم العملاء اللاسلكي أي من طرق التجوال السريعة التأمين المتاحة، فقد تحتاج إلى قبول حقيقة أن هؤلاء العملاء يمكنهم دائما تجربة التأخيرات الموضحة في هذا المستند عند التجوال بين نقاط الوصول على شبكة WLAN/SSID مع أمان 802.1X/EAP (الذي يمكن أن يتسبب في حالات انقطاع في تطبيقات/خدمات العميل).
• يتم دعم جميع الطرق، باستثناء SKC (WPA2 PMKID Caching)، للتجوال الآمن السريع بين نقاط الوصول التي تديرها وحدات تحكم الشبكة المحلية اللاسلكية (WLCs) مختلفة (التجوال بين وحدات التحكم)، طالما أنها موجودة على نفس مجموعة التنقل.
• يدعم CUWN بشكل كامل جميع طرق التجوال السريعة التأمين المختلفة المغطاة في هذه المادة عند إستخدام مصادقة 802. 1X/EAP ل WPA/WPA2. لا يدعم CUWN التجوال السريع الآمن على الطرق التي تعمل مع WPA2-RSN (CCKM، PMKID Caching/SKC، OKC/PKC) عند إستخدام PSK (WPA2-Personal)، حيث لا تكون هناك حاجة غالبا لطرق التجوال السريع. ومع ذلك، يدعم CUWN التجوال السريع والآمن في حالة WPA2-ft (802.11r) مع PSK كما هو موضح أيضا في هذه المقالة.

معلومات ذات صلة

• دليل نشر التحويل السريع ل 802.11r BSS
• الدعم الفني والتنزيلات من Cisco