lte-security-profile/docs/45.md

1. الزامات پروتکل DTLS

پیش از بیان الزامات DTLS برای جلوگیری از تکرار لازم است به لیست مجموعه‌های رمزنگاری قابل استفاده برای TLS و DTLS اشاره کنیم. این لیست در جدول 7-2 آورده شده و در خلال الزامات TLS و DTLS به آن مراجعه خواهیم کرد.

جدول 7-2 لیست الگوریتم‌های رمزنگاری برای پروتکل‌های TLS و DTLS

| TLS_RSA_WITH_AES_128_CBC_SHA مطابق با RFC 3268 | | TLS_RSA_WITH_AES_256_CBC_SHA مطابق با RFC 3268 | | TLS_DHE_RSA_WITH_AES_128_CBC_SHA مطابق با RFC 3268 | | TLS_DHE_RSA_WITH_AES_256_CBC_SHA مطابق با RFC 3268 | | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA مطابق با RFC 4492 | | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA مطابق با RFC 4492 | | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA مطابق با RFC 4492 | | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA مطابق با RFC 4492 | | TLS_RSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5246 | | TLS_RSA_WITH_AES_256_CBC_SHA256 مطابق با RFC 5246 | | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5246 | | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 مطابق با RFC 5246 | | TLS_RSA_WITH_AES_128_GCM_SHA256 مطابق با RFC 5288 | | TLS_RSA_WITH_AES_256_GCM_SHA384 مطابق با RFC 5288 | | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 مطابق با RFC 5288 | | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 مطابق با RFC 5288 | | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5289 | | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 مطابق با RFC 5289 | | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 مطابق با RFC 5289 | | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 مطابق با RFC 5289 | | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 مطابق با RFC 5289 | | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 مطابق با RFC 5289 | | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 مطابق با RFC 5289 | | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 مطابق با RFC 5289 |

در ادامه الزامات پروتکل DTLS بیان شده است. قابل ذکر است که در نسخه جدید از پروفایل حفاظتی برای محصولات شبکه، پیاده‌سازی قابلیت احراز هویت دوطرفه در DTLS و TLS به عنوان یک الزام اختیاری در نظر گرفته شده است. لذا این روند در این پروفایل حفاظتی نیز رعایت شده و در این قسمت الزامات این پروتکل‌ها بدون احراز هویت دوطرفه را بیان کرده‌ایم و در صورت تمایل به پیاده‌سازی احراز هویت دوطرفه باید الزامات اختیاری ذکر شده در آن بخش نیز علاوه بر الزامات این بخش رعایت شود.

قابل ذکر است که با توجه به کارکرد این پروتکل‌ها به فرم client/server، الزامات مربوطه نیز برای هر یک از کاربر (client) یا سرور (server) جداگانه بیان شده است که هر یک از دو طرف مودم و موجودیت دوم مانند سرور خارجی رکوردهای ممیزی می‌توانند نقش کاربر DTLS یا سرور DTLS را بگیرند.

نام الزام	شماره الزام
الزامات پروتکل Client DTLS بدون احراز هویت دوطرفه (1) (FCS_DTLSC_EXT.1.1)	1
مودم باید ]انتخاب: DTLS 1.2 (RFC 6347)، DTLS 1.0 (RFC 4347)[ را با پشتیبانی از مجموعه‌های رمز زیر پیاده‌سازی کند: ]انتخاب: یکی از مجموعه‌های رمزنگاری لیست‌شده در لیست الگوریتم‌های رمزنگاری برای پروتکل‌های TLS و DTLS[
الزامات پروتکل Client DTLS بدون احراز هویت دوطرفه (2) (FCS_DTLSC_EXT.1.2)	2
مودم باید مطابقت شناسه ارائه شده با شناسه مرجع را با توجه به بخش 6 از RFC 6125، تأیید کند. نکات کاربردی: قوانین مربوط به تأیید شناسه در بخش 6 از RFC 6125 توضیح داده شده‌اند.
الزامات پروتکل Client DTLS بدون احراز هویت دوطرفه (3) (FCS_DTLSC_EXT.1.3)	3
مودم کلاینت باید کانال امن را فقط در صورت معتبر بودن گواهینامه سرور برقرار سازد. اگر گواهینامه سرور نامعتبر به نظر رسید، مودم باید ]انتخاب: ارتباط را برقرار نسازد، برای برقراری ارتباط درخواست مجوز بدهد، ]اختصاص: دیگر اقدامات[[.
الزامات پروتکل Client DTLS بدون احراز هویت دوطرفه (4) (FCS_DTLSC_EXT.1.4)	4
مودم باید ]انتخاب: Extension Curves Elliptic Supported را ارائه نکند، Extension Curves Elliptic Supported را به همراه curve NIST‌های ]انتخاب: secp256r1، secp384r1، secp521r1[ و هیچ منحنی دیگری[ در پیام Client Hello ارائه دهد. نکات کاربردی: اگر در الزام "الزامات پروتکل Client DTLS بدون احراز هویت (1)" مجموعه‌های رمز دارای منحنی‌های بیضوی انتخاب گردند، در این الزام باید یک یا چند مورد از منحنی‌ها انتخاب شود. اگر در الزام مربوطه هیچ‌کدام از مجموعه‌های رمز دارای منحنی‌های بیضوی انتخاب نگردد، عبارت "Extension Curves Elliptic Supported را ارائه نکند" باید انتخاب شود. این الزام مجموعه‌های رمز بیضوی مجاز برای احراز هویت و توافق کلید را به منحنی‌های NIST از الزام‌های FCS_COP.1/SigGen و FCS_CKM.1 و FCS_CKM.2 محدود می‌سازد. این افزونه برای کلاینت‌هایی که از مجموعه‌های رمز بیضوی پشتیبانی می‌کنند، الزامی است.
الزامات پروتکل Server DTLS بدون احراز هویت دوطرفه (1) (FCS_DTLSS_EXT.1.1)	5
مودم باید ]انتخاب: DTLS 1.2 (RFC 6347)، DTLS 1.0 (RFC 4347)[ را با پشتیبانی از مجموعه‌های رمز زیر پیاده‌سازی کند: ]انتخاب: یکی از مجموعه‌های رمزنگاری لیست‌شده در لیست الگوریتم‌های رمزنگاری برای پروتکل‌های TLS و DTLS[
الزامات پروتکل Server DTLS بدون احراز هویت دوطرفه (2) (FCS_DTLSS_EXT.1.2)	6
مودم نباید برای کلاینت‌هایی که درخواست هیچ دارند، ارتباطات را ایجاد کند.
الزامات پروتکل Server DTLS بدون احراز هویت دوطرفه (3) (FCS_DTLSS_EXT.1.3)	7
مودم نباید در صورت شکست خوردن اعتبارسنجی Client DTLS، تلاش دست‌تکانی ارتباط را پیش ببرد. نکته کاربردی: فرآیند اعتبارسنجی Client DTLS در بخش 4.2.1 از DTLS v1.2 (RFC 6347) و DTLS v1.0 (RFC 4347) تشریح شده است. مودم با نقش سرور، DTLS Client را در طول فرایند برقراری اتصال (Handshaking) و پیش از ارسال پیام ServerHello اعتبارسنجی می‌کند. سرور بعد از دریافت پیام ClientHello، یک پیام HelloVerifyRequest را همراه با یک کوکی به کلاینت ارسال می‌کند. این کوکی در واقع یک پیام امضا شده با استفاده از توابع چکیده‌ساز معرفی شده در الزام FCS_COP.1/KeyedHash است. در ادامه کلاینت دوباره یک پیام ClientHello دیگر را به همراه کوکی امضا شده ذکر شده ارسال می‌کند. سرور در صورت تأیید کردن این کوکی ارسالی از جانب کلاینت، مطمئن می‌شود که کلاینت از آدرس IP جعلی استفاده نکرده است.
الزامات پروتکل Server DTLS بدون احراز هویت دوطرفه (4) (FCS_DTLSS_EXT.1.4)	8
مودم باید استقرار کلید را با استفاده از ]انتخاب: RSA با اندازه کلید ]انتخاب: 2048 بیت، 3072 بیت، 4096 بیت[، دیفی-هلمن با پارامترهایی با سایز ]انتخاب: 2048 بیت، 3072 بیت، 4096 بیت، 6144 بیت، 8192 بیت[، دیفی-هلمن با گروه‌های ]انتخاب: ffdhe2048، ffdhe3072، ffdhe4096، ffdhe6144، ffdhe8192، هیچ گروه دیگر[، منحنی‌های ECDHE ]انتخاب: secp256r1، secp384r1، secp521r1[ و هیچ منحنی دیگری[ انجام دهد.
الزامات پروتکل Server DTLS بدون احراز هویت دوطرفه (5) (FCS_DTLSS_EXT.1.5)	9
مودم باید هنگامی که یک پیام حاوی MAC نامعتبر دریافت می‌کند، ]انتخاب: به نشست DTLS خاتمه دهد، بی‌صدا رکورد را دور بریزد[. نکته کاربردی: کد MAC در طی فاز دست‌تکانی DTLS و برای حفاظت از جامعیت پیام‌ها استفاده می‌شود. اگر تأیید MAC شکست بخورد، نشست باید خاتمه یابد یا رکورد دریافت‌شده، بی‌صدا دور انداخته شود.
الزامات پروتکل Server DTLS بدون احراز هویت دوطرفه (6) (FCS_DTLSS_EXT.1.6)	10
مودم با نقش سرور باید پیام‌های باز ارسال شده (مربوط به replay attack) برای: رکوردهای DTLS که قبلاً دریافت شده‌اند (یعنی شماره ترتیب آن تکراری است)، رکوردهای DTLS بسیار قدیمی که شماره ترتیب آن‌ها در sliding receive window قرار نمی‌گیرد، را به صورت خاموش نادیده بگیرد. نکات کاربردی: حمله replay attack در RFC 6347 برای DTLS 1.2 و RFC 4347 برای DTLS 1.0 شرح داده شده است.