500 likes | 778 Views
Kerberos. فصل یازدهم. اهداف. آشنایی با چگونگی احراز هویت در الگوریتم کربروس. برا ي د ي دن معادل انگل ي س ي ترجمه ها به اسلا ي د لغت نامه مراجعه نماييد. کل ي د واژه ها:. افسانه ي ونان ي. سگ سه سر افسانه ي ونان ي : محافظان دروازه های جهنم! سرها نماد: Authentication Accounting Audit
E N D
Kerberos فصل یازدهم
اهداف • آشنایی با چگونگی احراز هویت در الگوریتم کربروس
براي ديدن معادل انگليسي ترجمه ها به اسلايد لغت نامهمراجعه نماييد. کليد واژه ها:
افسانه يوناني • سگ سه سر افسانه يوناني : محافظان دروازه های جهنم! • سرها نماد: • Authentication • Accounting • Audit • اکرچه در عمل تنها احراز هويت اعمال شد.
کربروس • احراز هويت بر اساس رمز نگاري کليد خصوصي • طراحي شده در MIT • به جاي احراز هويت در هر کارگزار به صورت توزيع شده، يک کارگزار خاص را به احراز هويت اختصاص ميدهيم • نسخه هاي 4 و 5 آن در حال استفاده هستند
ويژگيهاي عمومي کربروس • عمومي بودن(Common) • در محیط توزیع شده همراه با سرورهای متمرکز و غيرمتمركز • امنيت (Security) • ادعای اصلی • اطمينان (Reliability) • اطمينان از فعال بودن همه سرویس ها برای کاربران مجاز. • شفافيت (Transparency) • کاربران بايد سيستم را همانند يک سيستم ساده “شناسه و کلمه عبور” ببينند. • مقياس پذيري(Scalability) • قابليت كار با تعداد زيادي ماشين كاربر و كارگزار
ويژگيهاي عمومي کربروس چند تعریف • دامنه: يک محدوده دسترسی را مشخص می کند. به نوعی معادل دامنه های تعريف شده در ويندوز می باشد. • مرکز توزيع کليد: معادل کارگزار کربروس می باشد. • Principal : به سرويس ها، دستگاه ها، کاربران و کليه عناصری که احتیاج به شناساندن خود به کارگزار کربروس دارند، گفته می شود.
ديالوگ ساده احراز هويت-0 درخواست خدمات توسط کارفرما از کارگزار: • Client AS: IDclient || PassClient || IDServer • AS Client:Ticket • Client Server: IDclient || Ticket Ticket = EKserver [IDclient || Addrclient || IDserver] AS : Authentication Serverکارگزار احراز هويت
بليط در واقع نوعي گواهي است كه هنگام ورود كاربر به قلمرو کربروس به او داده مي شود كه بيانگر اعتبار او براي دسترسي به منابع شبكه مي باشد.
بررسی دیالوگ • چرا آدرس کارفرما در بليط ذکر ميشود؟ • در غیر این صورت هر شخصی که بلیط را از طریق شنود به دست آورد نیز میتواند از امکانات استفاده کند. اما اکنون تنها خدمات به آدرس ذکر شده در بلیط ارایه میشود. • مشکل جعل آدرس • چرا شناسه مشتری IDclient در گام سوم به صورت رمز نشده ارسال ميشود؟ • زیرا این اطلاعات به صورت رمزنگاری شده در بلیط وجود دارد. • اگر شناسه با بلیط مطابقت نداشته باشد خدمات ارایه نمیشوند.
مشکلات ديالوگ ساده احراز هويت-0 • ناامنی • ارسال كلمه عبور بدون رمزگذاري (بشكل متن واضح) • امکان حمله تکرار • ناکارآيی • لزوم تقاضای بلیط جدید برای هر خدمات
استفاده مجدد از بليطها • چرا استفاده مجدد از بليطها (Tickets) اهميت دارد؟ • جلوگيري از تايپ مجدد کلمه عبور در يک بازه زماني کوتاه • شفافیت احراز هویت • کاربر متوجه فرآيندهای هویت شناسی نمی شود.
افزایش ایمنی-ديالوگ 1 • استفاده از يک کارگزار جديد با نام کارگزار اعطا کننده بليط • TGS: Ticket Granting Server • کارگزار احراز هويت،AS، کماکان وجود دارد. • بليط “اعطاء بليط” ticket-granting ticket توسط آن صادر می شود. • اگرچه بليطهای اعطاء خدمات توسط TGS صادر ميشوند. • بليط “اعطاء خدمات” service-granting ticket • اجتناب از انتقال کلمه عبور با رمز کردن پيام کارگزار احراز هويت (AS)به کارفرما توسط کليد مشتق شده از کلمه عبور
1. IDClient || IDTGS • 3. IDClient || IDServer || TicketTGS • 2. EKClient [TicketTGS] 4. TicketServer جلسه Log In • 5. IDClient || TicketServer Server افزایش ایمنی-ديالوگ1 TGS Client کارفرما با کمک کلید مشترک خود و AS بلیط TGS را بازیابی میکند. AS
افزایش ایمنی-ديالوگ1 • پيامهاي شماره يک و دو به ازاء هر جلسه Log on رد و بدل ميشوند. • پيامهاي شماره سه و چهار به ازاء هر نوع خدمات رد و بدل ميشوند. • پيام شماره پنج به ازاء هر جلسه خدمات رد و بدل ميشود. • Client AS: IDClient || IDTGS • AS Client: EKClient [TicketTGS] • Client TGS: IDClient || IDServer || TicketTGS • TGS Client: TicketServer • Client Server: IDClient || TicketServer
محتوي بليط ها بلیط اعطای بلیط : بلیط اعطای خدمات :
ويژگي هايديالوگ 1 • دو بليط صادر شده ساختار مشابهی دارند. در اساس به دنبال هدف واحدی هستند. • رمزنگاری TicketTGS جهت احراز هویت • تنها کارفرما می تواند به بليط رمزشده دسترسی پيدا کند. • رمز نمودن محتوای بلیطها تمامیت (Integrity) را فراهم میکند. • استفاده از مهر زمانی (Timestamp) در بلیطها آنها را برای یک بازه زمانی تعریف شده قابل استفاده مجدد میکند. • هنوز از آدرس شبکه برای احراز هویت بهره میگیرد. • چندان جالب نیست زیرا آدرس شبکه جعل (Spoof) میشود. • با این حال، درجه ای از امنیت مهیا می شود
نقاط ضعف ديالوگ 1 • مشكل زمان اعتبار بلیطها: • زمان كوتاه : نياز به درخواست هاي زياد گذرواژه • زمان بلند : خطر حمله تکرار • هويت شناسی يکسويه : عدم احراز هويت کارگزارتوسط كارفرما • رسيدن درخواست ها به يك کارگزارغيرمجاز
کربروس نسخه 4 • توسعه یافته پروتکل های قبلی است • مشکل حمله تکرار حل شده است. • احراز هویت دو جانبه (mutual) برقرار میشود. • کارگزاران و کارفرمایان هردو از هویت طرف مقابل اطمینان حاصل میکنند
مقابله با حمله تکرار • کارگزار یا TGS باید اطمینان حاصل نمایند که کاربر بلیط همان کسی است که بلیط برای او صادر شده. • مفهوم جدیدی به نام اعتبار نامه(Authenticator) ابداع شده است: • علاوه بر بلیط ها • از مفهوم کلید جلسه بهره میجوید
1. IDClient|IDtgs|TS1 2. EKClient[KClient,tgs|IDtgs|TS2|Lifetime2|Tickettgs] کربروس نسخه 4:بررسي الگوريتم-1 Client AS Tickettgs=EKtgs[KClient,tgs|IDClient|AddrClient|IDtgs|TS2|Lifetime2]
تمامی با کلید TGS رمز شده اند بلیط TGS Tickettgs=EKtgs[KClient,tgs|IDClient|AddrClient|IDtgs|TS2|Lifetime2] کلید جلسه بین کارفرما و TGS شناسهکارفرما مهر زمانی و دوره اعتبار بلیط آدرس کارفرما شناسهTGS
نتايج اين مرحله براي كارفرما • بدست آوردن امنبليط “اعطاء بليط” از AS • بدست آوردن زمان انقضاي بليط(TS2) • بدست آوردن كليد جلسه امن بين کارفرما و TGS
4. EKClient,tgs[KClient,server|IDserver|TS4|Ticketserver] 3. IDserver|Tickettgs|AuthenticatorClient بدست آوردن بليط “اعطاء خدمات” Client TGS TicketServer= EKserver[KClient,server|IDClient|AddrClient|IDserver|TS4|Lifetime4] AuthenticatorClient= EKClient,tgs[IDClient|AddrClient|TS3]
تمامی با کلید کارگزار رمز شده اند بلیط کارگزار TicketServer=EKserver[KClient,server|IDClient|AddrClient|IDserver|TS4|Lifetime4] کلید جلسه بین کارفرما و کارگزار شناسهکارفرما مهر زمانی و دوره اعتبار بلیط آدرس کارفرما شناسهTGS
تمامی با کلید جلسه رمز شده اند مهر زمانی شناسهکارفرما آدرس کارفرما اعتبار نامه کارفرما AuthenticatorClient=EKClient,tgs[IDClient|AddrClient|TS3]
نتايج اين مرحله براي كارفرما • جلوگيري از حمله تکرار با استفاده از يكاعتبار نامه (Authenticator) يكبار مصرف كه عمر كوتاهي دارد. • بدست آوردن كليد جلسه براي ارتباط با سرور V
5. TicketServer|AuthenticatorClient 6. EKClient,Server [TS5+1] دستيابي به خدمات سرور Server Client
نتايج اين مرحله براي كارفرما • احراز هويتکارگزار در گام ششم با برگرداندن پيغام رمزشده • جلوگيري از بروز حمله تکرار
قلمرو کربروس • قلمرو کربروس از بخشهاي زير تشكيل شده است: • کارگزار کربروس • کارفرمایان • کارگزاران كاربردي Application Servers • کارگزار کربروس گذرواژه تمام کاربران را در پایگاه داده خود دارد. • کارگزار کربروس با هر کارگزار كاربردي کلیدی مخفی به اشتراک گذاشته است. • معمولاً هر قلمرو معادل یک حوزه مدیریتی میباشد.
هويت شناسي بين قلمرويي(InterRealm) • امكان اينكه كاربران بتوانند از خدمات موجود در قلمروهاي ديگر استفاده كنند. • کارگزاران کربروسهر قلمرو يك كليد مخفي با کارگزارانکربروس قلمرو همکار مقابل به اشتراک میگذارند. • وجود N قلمرو همکار نیازمند N(N-1)/2 کلید مخفی است. • دو کارگزار کربروس همدیگر را ثبت نام مینمایند.
کربروس نسخه 5 • مشخصات • در اواسط 1990 مطرح شد • نقص ها و كمبودهاي نسخه قبلي را برطرف كرده است • به عنوان استاندارد اينترنتي RFC 1510 در نظر گرفته شده است. • ويندوز 2000 ازاستاندارد اينترنتی کربروس نسخه 5 بعنوان روش اصلی هويت شناسی کاربران استفاده می کند.
مشكلات Kerberos v4 و نحوه رفع آنها در نسخه 5 • وابستگي به يك سيستم رمزنگاري خاص(DES) + در نسخه 5 مي توان از هر الگوريتم متقارن استفاده كرد • وابستگي به IP + در نسخه 5 مي توان از هر آدرس شبكه(مثلا OSI يا IP) استفاده كرد • محدود بودن زمان اعتبار بليطها + در نسخه 5 اين محدوديت وجود ندارد
مشكلات Kerberos v4 و نحوه رفع آنها در نسخه 5 • امكان انتقال اعتبار يك كاربر به يك سرور ديگر وجود ندارد + در نسخه 5 اجازه داده مي شود كه مثلا كاربر به سرور چاپ يك فايل را معرفي كند تا فايل با اعتبار آن كاربر توسط سرور چاپ، چاپ شود (در يك ماشين ديگر) • با افزايش تعداد قلمروها، تعداد كليدها بصورت تصاعدي افزايش مي يابد + در نسخه 5 اين مشكل حل شده است.
پیاده سازی های موجود • دانشگاه MIT : اولين پياده سازی کربروس که هنوز به عنوان مرجع مورد استفاده قرار می گیرد • Heimdal : تنها پياده سازی انجام شده در خارج آمريکا • Active Directory : پياده سازی ارائه شده توسط مايکروسافت که در RFC 1510 آمده است