بررسی انواع پروتکل های EAP

نویسنده: مهنا حسینی
4 ماه پیش

بررسی انواع پروتکل های EAP

استاندارد 802.1x پروتکل لایه 2 ای است که برای کنترل دسترسی به شبکه بر اساس پورت کاربر طراحی شده است. این پروتکل از احراز هویت منحصر به فرد به ازای هر کاربر یا دستگاه استفاده می کند که به آن سرویس Port-level Authentication گفته می شود. فریمورک 802.1x، سه Role را در فرآیند احراز هویت تعریف می­ کند که شامل Authenticator ،Supplicant و Authentication Server است.

  1. Supplicant: به Endpoint ای گفته می­ شود که خواهان اتصال و دسترسی به شبکه است این Endpoint می ­تواند دستگاه کاربر، پرینتر یا IP Phone باشد.
  2. Authenticator: دستگاهی است که بین Supplicant و Authentication Server قرار می­ گیرد و احراز هویت را تسهیل می ­کند. کاربر معمولا به صورت مستقیم به Authenticator متصل است. برای مثال سوئیچ یا اکسس پوینت می­ تواند این سرویس را برای دسترسی کاربر به شبکه فراهم کند. شایان ذکر است که Authenticator با نام­ های AAA Client، Network Access Device (NAD) و Policy Enforcement Point (PEP) نیز شناخته می­ شود.
  3. Authentication Server: سروری است که هویت Supplicant را شناسایی و تایید می­ کند و به Authenticator اعلام می­ کند که به درخواست دسترسی کاربر پاسخ Allow یا Deny دهد.

شکل زیر این Role ها را نمایش می دهد.

EAP Roles

پیش از احراز هویت کاربر، پورت فقط اجازه عبور ترافیک EAPOL، CDP و STP را می ­دهد. بعد از اینکه احراز هویت موفقیت ­آمیز بود، ترافیک معمولی می­ تواند از روی پورت عبور کند.

802.1x Interworking

در این بخش راه ­های ارتباطی 802.1x شرح داده شده است.

Extensible Authentication Protocol (EAP)

EAP یک مکانیزم انتقال است که در استاندارد 802.1x برای احراز هویت Supplicant در مقابل Data Store ای مانند Radius Server استفاده می ­شود. EAP در ابتدا به عنوان Framework متداول احراز هویت که روی پروتکل Point-to-Point لایه 2 اجرا می ­شود، تعریف شد. سپس به عنوان پروتکل Link Layer به روز رسانی شد. فرمت بسته EAP به صورت زیر است:

EAP Frame

در ادامه به توضیح فیلد های این بسته می پردازیم:

  • Code: فیلد Code یک بایت و نشان دهنده نوع بسته EAP است. در جدول زیر انواع Code ها نشان داده شده است.
کد توضیحات
1 Request
2 Response
3 Success
4 Failure

بسته ­های EAP با Code های دیگر Discard می­ شوند.

  • Identifier: این فیلد نیز یک بایت است و Response و Request را با هم تطبیق می ­دهد.
  • Length: این فیلد دو بایت است و طول بسته EAP که شامل Code ،Identifier ،Length و فیلد داده است، را نشان می ­دهد.
  • Data: فیلد Data، صفر بایت یا بیش­تر است. فیلد Code، مقدار این فیلد را مشخص می ­کند.

EAP over LAN (EAPOL)

در محیط LAN، نقش های Supplicant و Authenticator با استفاده از تکنیک Encapsulation که به عنوان EAPOL شناخته می­ شود، با یکدیگر ارتباط برقرار می­ کنند. EAPOL از بسترهای ارتباطی مختلف از جمله Ethernet، Token Ring، FDDI و WLAN پشتیبانی می­ کند. EAPOL قابلیت Encapsulate کردن پیام­ های EAP را فراهم می ­کند. فریم EAPOL نسبتا ساده است، بسته EAP داخل آن کپسوله شده و در فیلد Packet Body قرار می گیرد. فرمت فریم EAPOL به صورت زیر است:

EAOPL Frame

فیلد مک آدرس مبدا و مقصد هر دو 6 بایت هستند و مشابه ترافیک نرمال Ethernet مورد استفاده قرار می ­گیرند. محتوای فیلد مک آدرس مقصد همیشه ثابت و برابر با 01:80:C2:00:00:03 بوده که مربوط به Port Access Entity (PAE) است. فیلد PAE Ethernet Type دو بایتی و مقدار آن همیشه 88:8E است. فیلد Packet Type نیز یک بایتی و مقدار آن نشان دهنده نوع بسته می ­باشد که در جدول زیر این مقادیر نمایش داده شده است:

نوع مقدار
EAP-Packet 0000 0000 (0)
EAPOL-Start 0000 0001 (1)
EAPOL-Logoff 0000 0010 (2)
EAPOL-Key 0000 0011 (3)
EAPOL-Encapsulated-ASF-Alert 0000 0100 (4)

فیلد Packet Body Length یک فیلد دو بایتی است و طول بسته (Packet Body) را مشخص می ­کند. اگر این مقدار صفر باشد، بیانگر این است که فیلد Packet Body وجود ندارد. در واقع زمانی فیلد Packet Body وجود دارد که نوع بسته،EAP-Packet ، EAPOL-Key یا EAPOL-Encapsulated-ASF-Alert باشد.

EAP Message Exchange

EAP Message Exchange

بسته ­های EAP از Supplicant تا Authenticator به صورت EAPOL و از Authenticator تا Authentication Server، درون بسته ­های Radius کپسوله می ­شوند. در ادامه توضیح داده می ­شود که در هر مرحله چه اتفاقی رخ می دهد.

  • مرحله 1: Supplicant یک فریم EAPOL-Start به Authenticator ارسال می­ کند تا به آن اعلام کند که آماده احراز هویت است. اگر Authenticator آغاز کننده این ارتباط باشد، هیچ بسته ­ای تحت عنوان EAPOL-Start ارسال نخواهد شد.
  • مرحله 2: Authenticator به محض تشخیص فعال شدن لینک، یک بسته EAP-Request/Identity به Supplicant ارسال می­ کند. (مثلا زمانی­ که کاربر به یک پورت سوئیچ متصل شود.)
  • مرحله 3: Supplicant یک بسته EAP-Response/Identity به Authenticator و سپس Authenticator بسته دریافتی را به Authentication Server ارسال می­ کند. بسته به نوع پروتکل مورد استفاده Radius Server، نحوه انتقال درخواست از Supplicant به Authentication Server متفاوت است.
  • مرحله 4: Authentication Server یک Challenge مانند Token Password System به Authenticator ارسال می­ کند. Authenticator آن را از بسته IP خارج کرده و مجددا درون EAPOL بسته ­بندی و به سمت Supplicant می فرستد. با توجه به نوع روش ­های Authentication، نوع و تعداد پیام ­ها می ­تواند متفاوت باشد. EAP می ­تواند از دو حالت Authentication پشتیبانی کند. در حالت اول فقط کاربر توسط Authentication Server احراز هویت می ­شود اما در حالت دوم هم Authentication Server و هم کاربر یکدیگر را احراز هویت می ­کنند. برای محیط ­های Wireless استفاده از حالت دوم مناسب تر است.
  • مرحله 5: در این وضعیت Supplicant به Challenge پاسخ می ­دهد. این پاسخ از طریق Authenticator به Authentication Server ارسال می ­شود.
  • مرحله 6 : اگر هویت Supplicant تایید شود، Authentication Server یک پیام Success به Supplicant ارسال می­ کند و سپس Authenticator اجازه دسترسی به شبکه را می دهد اما بر اساس اطلاعات ارسالی توسط Authentication Server، ممکن است این دسترسی محدود شود. به طور مثال Authenticator،Supplicant را در VLAN خاصی قرار دهد و یا بر روی پورت Supplicant یک ACL اعمال کند.

در شکل زیر این مراحل نشان داده شده است.

EAP Message Exchange

EAP Type Selection

EAP به دو دسته تقسیم می ­شود:

  • Native EAP
  • Tunneled EAP

نوع Tunneled EAP از یک Non tunneled EAP درون یک ارتباط TLS، بین Supplicant و Authentication Server استفاده می ­کند. در شکل زیر این دو مورد نشان داده شده است.

EAP Types

روش های مختلفی برای احراز هویت توسط EAP برای شبکه ­های Wired و Wireless وجود دارد. پرکاربرد ترین روش­ ها به شرح زیر می باشند:

  • EAP-TLS
  • EAP-MSCHAPv2
  • EAP-GTC
  • EAP-MD5
  • LEAP
  • EAP-TTLS
  • PEAP
  • EAP-FAST

در نوع Native EAP روش­ های EAP-MD5، EAP-TLS، EAP-MSCHAPv2 و EAP-GTC استفاده می ­شوند. در نوع Tunneled EAP ابتدا Tunnel امن شکل می­ گیرد و سپس اطلاعات هویتی درون Tunnel ارسال می ­شود. EAP-TTLS، PEAP و EAP-FAST در این دسته قرار می ­گیرند که می ­توانند از متد های دیگر به عنوان روش داخلی (Inner Method) استفاده کنند.

در جدول زیر انواع بسته ­های EAP بر اساس کد نشان داده شده است که در ادامه به بررسی روش ­های احراز هویت بر اساس هر یک از کدهای زیر می پردازیم:

نوع توضیحات
4 MD5-Challenge
13 EAP-TLS
21 EAP-TTLS
25 PEAP
29 EAP-MSCHAP-V2
43 EAP-FAST

EAP–TLS (Transport Layer Security)

EAP-TLS استانداردی است که توسط مایکروسافت توسعه یافت و توسط IETF پذیرفته شد. این استاندارد بر پایه پروتکل Transport Layer Security (TLS) است. در EAP-TLS، کاربر و سرور یکدیگر را احراز هویت می ­کنند. با این تفاوت که در این روش پسورد مورد استفاده قرار نمی ­گیرد و به جای آن از RSA Handshake استفاده می ­شود. EAP-TLS از Certificate یا Smart Card برای احراز هویت کاربر و سرور استفاده می­ کند.

در فاز اول Radius Server، گواهینامه (Certificate) خود را برای کاربر ارسال می­ کند و کاربر برای بررسی صحت آن، محتوای Certificate را با صادر کننده آن یعنی CA چک می­ کند. بعد از اینکه این مرحله با موفقیت انجام شد، در فاز دوم کاربر Certificate خود را برای Radius Server می فرستد. Radius Server نیز محتوای Certificate دریافتی را با صادر کننده آن بررسی می کند.

بعد از اینکه این مرحله نیز با موفقیت به اتمام رسید، یک پیام EAP-Success به کاربر ارسال می ­شود. مهم ترین مزیت EAP-TLS امنیت بالا به دلیل استفاده از یکی از قوی ­ترین روش ­های احراز هویت موجود به صورت دو طرفه می باشد. پیچیدگی زیاد پیاده­ سازی و نگهداری زیرساخت PKI از معایب EAP-TLS است. در واقع به دلیل نیاز به اجزای بیشتری مانند CA و Certificate کاربران، مدیران شبکه سازمان ها در بسیاری از موارد علاقه مند به استفاده از این روش نمی باشند.

در تصویر زیر فریم متد EAP-TLS نمایش داده شده است.

EAP TLS

EAP-MSCHAPv2

در این روش اطلاعات هویتی کاربر داخل MSCHAPv2 Session رمز شده و به سرور ارسال می ­شود. این روش انتقال راحت Username و Password، یا حتی Computer Name و Computer Password را به Radius Server فراهم می­ کند که در نهایت AD احراز هویت آن ­ها را انجام می ­دهد.

EAP-GTC

EAP-Generic Token Card (GTC) توسط سیسکو به عنوان جایگزینی برای MSCHAPv2 ارائه شد. این روش اجازه احراز هویت بر اساس هر نوع Identity Store را می ­دهد. این Identity Store ها شامل OTP token server، LDAP و ... می ­شود.

EAP-MD5 (Message Digest Algorithm 5)

EAP-MD5 براساس Message Digest Algorithm 5 (MD5) احراز هویت را انجام می­ دهد. در این روش هویت کاربر به صورت Hash شده روی شبکه ارسال می ­شود و سرور یک رشته تحت عنوان Challenge به صورت تصادفی تولید کرده و آن را به کاربر ارسال می ­کند. کاربر این رشته را با استفاده از پسورد خود که به عنوان کلید در نظر می ­گیرد، Hash کرده و به سرور ارسال می ­کند. سرور نیز Random String را با پسورد کاربر که از قبل در Database وجود دارد، Hash می ­کند. سپس Hash خود را با Hash ارسالی توسط کاربر مقایسه می ­کند.

یک مکانیزم احراز هویت ساده با استفاده از Username و Password فراهم می­ شود. هم چنین به دلیل پردازش ساده، بار پردازشی زیادی به سرور یا کاربر تحمیل نخواهد شد. اما به دلیل اینکه باید پسورد تمامی کاربران به صورت Plain-text یا قابل برگشت در Authentication Server ذخیره شود، در عملکرد دارای نقطه ضعف است. در EAP-MD5 احراز هویت به صورت یک طرفه انجام می­ گیرد و فقط Authentication Server امکان احراز هویت کاربر را دارد. این روش برای IP Phone ها متداول است. هم­ چنین بعضی از سوئیچ ­ها از EAP-MD5 برای ارسال درخواست MAC Authentication Bypass (MAB) استفاده می­ کنند.

در تصویر زیر نمونه فریم EAP-MD5 نمایش داده شده است.

EAP MD5

Cisco Lightweight EAP (LEAP)

Cisco Lightweight EAP (LEAP) روشی است که توسط سیسکو ارائه شده و مکانیزم آن شبیه EAP-MD5 است. در این روش کاربر و سرور هر دو یکدیگر را احراز هویت می ­کنند. کاربر برای احراز هویت، از Shared Secret و سرور از پسورد کاربر استفاده می ­کند. در این حالت سرور یک Challenge (رشته) برای کاربر ارسال می ­کند و کاربر آن را با پسورد خود Hash کرده و به سرور ارسال می کند. سرور رشته را با پسورد مربوط به کاربر که در Database خود دارد، Hash می­ کند و مقدار آن را با پاسخ دریافتی از کاربر مقایسه می ­کند. بعد از اینکه احراز هویت کاربر توسط سرور انجام شد، کاربر هویت سرور را مورد بررسی قرار می ­دهد.

در این حالت کاربر یک رشته تولید می ­کند و برای سرور ارسال می ­کند و سرور رشته را با Shared Secret خود Hash می کند و برای کاربر ارسال می کند. کاربر نیز رشته را با Shared Secret که از قبل برای آن مشخص شده است، Hash کرده و دو Hash را با هم مقایسه می ­کند و بدین ترتیب سرور توسط کاربر احراز هویت می ­شود. زمانی ­که این فرایند کامل شد، یک پیام EAP-Success به کاربر ارسال می ­شود.

EAP-TTLS (Tunneled Transport Layer Security)

EAP-TTLS بر اساس مفاهیم EAP-TLS گسترش یافته است و به لحاظ عملکرد شبیه PEAP می ­باشد. این روش دارای دو فاز است.

  • EAP-TTLS همانند EAP-TLS از TLS برای ایجاد Tunnel بین Authentication Server و Supplicant استفاده می ­کند و فاز یک را تشکیل می ­دهد.
  • EAP-TTLS همانند PEAP از TLS Tunnel برای کپسوله کردن فرم ­های دیگر EAP استفاده می­ کند اما تفاوت آن با PEAP، پشتیبانی از روش­ هایی مانند PAP و CHAP می باشد. EAP-TTLS بر خلاف EAP-TLS نیاز به احراز هویت دو طرفه ندارد که باعث ساده تر شدن پیاده سازی می شود.

در تصویر زیر فریم متد EAP-TTLS نمایش داده شده است:

EAP TTLS

Protected EAP (PEAP)

Protected EAP (PEAP) به صورت مشترک توسط Cisco Systems ،Microsoft و RSA Security ارائه شده است و از روش ­های مختلف کپسوله کردن EAP درون Transport Layer Security (TLS) tunnel پشتیبانی می­ کند.

PEAP از مجموعه گسترده ­ای از روش ­های احراز هویت کاربران پشتیبانی می­ کند. در سمت سرور از Certificate که بر پایه استاندارد Public-Key Infrastructure (PKI) است، برای احراز هویت استفاده می­ شود. PEAP می ­تواند در محیط ­هایی که برای هر کاربر Certificate صادر نمی ­شود، از یوزر و پسوردهای ویندوزی برای احراز هویت استفاده کند. این یوزر و پسوردها می توانند تحت Domain یا به صورت Local باشند.

عملکرد PEAP از دو فاز تشکیل شده است :

  • فاز 1: در این فاز یک Tunnel امن میان Supplicant و Server تشکیل می شود. این Tunnel برای حمل بسته­ های احراز هویت EAP بین کاربر و Radius Server مورد استفاده قرار می ­گیرد.
  • فاز 2: Radius Server کاربر را به وسیله MS-CHAP version 2، EAP-GTC و یا EAP-TLS، در بستر Tunnel امنی که ایجاد شده، احراز هویت می­ کند و پیام EAP-Success را در صورت موفقیت به سمت کاربر ارسال می نماید.

در تصویر زیر نمونه فریم PEAP نمایش داده شده است:

PEAP

EAP–FAST (Flexible Authentication via Secure Tunneling)

سیسکو EAP–Flexible Authentication via Secure Tunneling (EAP-FAST) را به عنوان جایگزینی برای PEAP و به منظور پشتیبانی از مشتریانی که نیاز به سیاست­ های قوی در زمینه پسورد دارند اما تمایل به پیاده ­سازی Certificate ندارند، ارایه کرده است. EAP-FAST محافظتی را در برابر حملات مختلف شبکه از جمله Man-in-the middle، Replay و Dictionary attack فراهم می ­آورد.

این متد نیز شباهت هایی با PEAP دارد. در ابتدا یک Outer Tunnel تشکیل داده، سپس احراز هویت را توسط Inner Method انجام می دهد. با این تفاوت که جهت تشکیل Outer Tunnel به جای Certificate از PAC (Protected Access Credential) استفاده می شود.

این مکانیزم در سه فاز صورت می گیرد:

فاز 0 - PAC Provisioning:

در این فاز PAC File به Supplicant ارایه می گردد. این مرحله به صورت Automatic و یا Manual قابل انجام است. PAC File تنها در بازه های زمانی مشخص نیاز به به روز رسانی دارد.

فاز 1 - TLS Tunnel Establishment:

در این مرحله کاربر و سرور با استفاده از PAC یکدیگر را احراز هویت کرده و Tunnel را برقرار می­ کنند.

فاز 2 - Authentication:

در مرحله آخر با بهره گیری از Inner Method احراز هویت کاربر با ارسال Credential، صورت می گیرد.

بر خلاف سایر روش ­ها برای پیاده­ سازی EAP-Fast به Network Access Manager (NAM) یا همان Cisco Any Connect نیاز است. یکی از مهم ترین ویژگی های EAP-Fast پشتیبانی از قابلیت EAP-Chaining می باشد. به کمک این قابلیت می توان در یک Radius-Session، کاربر و ماشین عضو Domain را احراز هویت نمود.

در تصویر زیر نمونه یک فریم EAP-Fast نشان داده شده است:

EAP FAST

184
0
2
نظرات