Please enter banners and links.
Network Working Group B. Aboba Request for Comments: 3575 Microsoft Updates: 2865 July 2003 Category: Standard Track
Согласование с IANA для протокола RADIUS
IANA Considerations for RADIUS
(Remote Authentication Dial In User Service)
Статус документа
Этот документ содержит спецификацию проекта стандартного протокола Internet и служит приглашением к дискуссии в целях развития протокола. Текущее состояние стандартизации и статус протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться свободно.
Авторские права
Copyright (C) The Internet Society (2003). Все права защищены.
Тезисы
Этот документ описывает вопросы, требующие согласования с агентством IANA1, в части протокола RADIUS2.
Документ служит обновлением RFC 2865.
1. Введение
В этом документе приведены рекомендации для агентства IANA, относящиеся к регистрации значений, связанных с протоколом RADIUS, который определен в [RFC2865], в соответствии с документом BCP 26, [RFC2434]. Документ также резервирует коды типа пакетов, которые используются или будут использоваться в Internet.
1.1. Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].
1.2. Терминология
Термины «пространство имен» (name space), «выделенное значение» (assigned value), «регистрация» (registration) трактуются в соответствии с определениями BCP 26.
Процедуры распределения «для приватного использования» (Private Use), «в порядке очередности» (First Come First Served), «экспертная оценка» (Expert Review), «требуется спецификация» (Specification Required), «одобрение IESG» (IESG Approval), «согласие IETF» (IETF Consensus), «стандартизация» (Standards Action) трактуются здесь в соответствии с определениями BCP 26.
2. Согласование с IANA
В протоколе RADIUS имеется три пространства имен, требующих регистрации: коды типа пакетов (Packet Type Code), типы атрибутов (Attribute Type) и значения атрибутов (Attribute Value) (для некоторых атрибутов). Этот документ не создает новых реестров IANA, поскольку реестры для протокола RADIUS были созданы в [RFC2865].
RADIUS не относится к протоколам общего назначения и выделение значений не следует выполнять с целями, отличными от AAA3.
2.1. Рекомендуемые правила регистрации
Для регистрационных запросов, где следует консультироваться с назначенным экспертом (Designated Expert), такого эксперта следует назначать ответственному директору направления IESG. Это сделано для того, чтобы любая регистрация сопровождалась публикацией RFC. Тем не менее, эксперт может одобрить регистрацию до публикации документа в том случае, когда он понимает, что RFC будет опубликован. Эксперт будет направлять запрос в список рассылки AAA WG (или другой список, указанный руководителем направления) для получения комментариев и рецензирования, включая документ Internet-Draft. Не позже 30 после этого эксперт должен будет принять или отвергнуть запрос на регистрацию, опубликовав свое решение в списке рассылок AAA WG (или заменяющей его конференции), а также сообщить свое решение агентству IANA. Отказ должен сопровождаться разъяснением причин и, по возможности, рекомендациями по корректировке запроса для возможности его удовлетворения.
Значения Packet Type Code занимают диапазон от 1 до 253. Коды RADIUS Type в диапазонах 1-5 и 11-13 были выделены в [RFC2865], а коды 40-45 и 250-253 — в настоящем документе. Коды 250-253 предназначены для экспериментов (Experimental Uses), а коды 254-255 зарезервированы. Значения Packet Type Code 6-10, 12-13, 21-34 и 50-51 не выделены в каких-либо документах IETF RFC и остаются резервными до появления соответствующих спецификаций. Это позволит избежать проблем при взаимодействии с нестандартными расширениями RADIUS, которые используются или будут использоваться в сети Internet. Поскольку новые значения кодов Packet Type будут оказывать существенное влияние на интероперабельность, для выделения новых значений Packet Type Code требуется одобрение IESG (IESG Approval). Это сделано для того, чтобы выделение значений сопровождалось публикацией RFC. В первую очередь следует распределять коды 52-249, а затем 14-20, 35-39 и 46-49. Список кодов типа приведен в Приложении A.
Типы атрибутов имеют значения в диапазоне от 1 до 255 и относятся к числу дефицитных ресурсов RADIUS, поэтому распределять значения нужно с осторожностью. Атрибуты типов 1-53, 55, 60-88, 90-91, 94-100 уже выделены, при этом значения 17 и 21 могут быть выделены для нового применения. Атрибуты типов 17, 21, 54, 56-59, 89, 101-191 могут выделяться с согласия IETF (IETF Consensus). Выделять значения типов 17 и 21 рекомендуется только по исчерпании других значений.
Отметим, что в протоколе RADIUS определен механизм фирменных (Vendor-Specific) расширений (Attribute 26) для функций, применяемых только в реализациях RADIUS одного производителя, когда не возникает требований по совместимости. Для функций, присущих только реализациям одного производителя, рекомендуется использовать этот тип вместо выделения глобального типа атрибута.
В [RFC2865] сказано:
Значения 192-223 предназначены для экспериментальных целей, значения 224-240 зарезервированы для разработчиков (специфические для реализации типы), а значения 241-255 являются резервными и не должны использоваться.
Следовательно, значения Attribute Type из диапазона 192-240 рассматриваются в качестве предназначенных для приватных систем (Private Use), а для значений 241-255 требуется стандартизация (Standards Action).
Некоторые атрибуты (например, NAS-Port-Type) протокола RADIUS определяют набор значений в соответствии с разными смыслами. Для каждого атрибута может существовать до 232 значений. Дополнительные значения могут быть выделены в соответствии с процедурой Designated Expert. Исключением из этого правила является атрибут Service-Type (6), значения которого определяют новые режимы работы RADIUS. Значения 1-16 для этого атрибута уже выделены. Для выделения новых значений Service-Type используется согласование с IETF (IETF Consensus). Это сделано для того, чтобы выделение каждого значения сопровождалось публикацией RFC.
3. Литература
3.1. Нормативные документы
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 2434, October 1998.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, “Remote Authentication Dial In User Service (RADIUS)”, RFC 2865, June 2000.
3.2. Дополнительная литература
[RFC2607] Aboba, B. and J. Vollbrecht, “Proxy Chaining and Policy Implementation in Roaming”, RFC 2607, June 1999.
[RFC2866] Rigney, C., “RADIUS Accounting”, RFC 2866, June 2000.
[RFC2867] Zorn, G., Aboba, B. and D. Mitton, “RADIUS Accounting Modifications for Tunnel Protocol Support”, RFC 2867, June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, “RADIUS Attributes for Tunnel Protocol Support”, RFC 2868, June 2000.
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, “RADIUS Extensions”, RFC 2869, June 2000.
[RFC2869bis] Aboba, B. and P. Calhoun, “RADIUS Support for Extensible Authentication Protocol (EAP)”, Work in Progress5.
[RFC2882] Mitton, D., “Network Access Servers Requirements: Extended RADIUS Practices”, RFC 2882, July 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, “RADIUS and IPv6”, RFC 3162, August 2001.
[DynAuth] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, “Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)”, RFC 3576, July 2003.
4. Вопросы безопасности
Вопросы безопасности, рассмотренные в [RFC2434], в общем случае применимы и к настоящему документу. Вопросы безопасности, связанные с протоколом RADIUS, рассмотрены в документах [RFC2607], [RFC2865], [RFC3162], [DynAuth] и [RFC2869bis].
Приложение A – Типы пакетов RADIUS
Ниже приведен список кодов RADIUS Packet Type. Этот список является инструкцией агентству IANA по публикации значений в реестре Packet Type Codes. Отметим, что коды 40-45, определенные в [DynAuth], формально выделены настоящим документом. Коды 40-45 были указаны в [RFC2882] и применяются в реализациях. С учетом широкого распространения этих кодов их следует считать практически не возвратными.
Номер
|
Имя сообщения
|
Документ
|
1
|
Access-Request
|
[RFC2865]
|
2
|
Access-Accept
|
[RFC2865]
|
3
|
Access-Reject
|
[RFC2865]
|
4
|
Accounting-Request
|
[RFC2865]
|
5
|
Accounting-Response
|
[RFC2865]
|
6
|
Accounting-Status6
|
[RFC2882]
|
7
|
Password-Request
|
[RFC2882]
|
8
|
Password-Ack
|
[RFC2882]
|
9
|
Password-Reject
|
[RFC2882]
|
10
|
Accounting-Message
|
[RFC2882]
|
11
|
Access-Challenge
|
[RFC2865]
|
12
|
Status-Server7
|
[RFC2865]
|
13
|
Status-Client2
|
[RFC2865]
|
21
|
Resource-Free-Request
|
[RFC2882]
|
22
|
Resource-Free-Response
|
[RFC2882]
|
23
|
Resource-Query-Request
|
[RFC2882]
|
24
|
Resource-Query-Response
|
[RFC2882]
|
25
|
Alternate-Resource-Reclaim-Request
|
[RFC2882]
|
26
|
NAS-Reboot-Request
|
[RFC2882]
|
27
|
NAS-Reboot-Response
|
[RFC2882]
|
28
|
Reserved
|
|
29
|
Next-Passcode
|
[RFC2882]
|
30
|
New-Pin
|
[RFC2882]
|
31
|
Terminate-Session
|
[RFC2882]
|
32
|
Password-Expired
|
[RFC2882]
|
33
|
Event-Request
|
[RFC2882]
|
34
|
Event-Response
|
[RFC2882]
|
40
|
Disconnect-Request
|
[DynAuth]
|
41
|
Disconnect-ACK
|
[DynAuth]
|
42
|
Disconnect-NAK
|
[DynAuth]
|
43
|
CoA-Request
|
[DynAuth]
|
44
|
CoA-ACK
|
[DynAuth]
|
45
|
CoA-NAK
|
[DynAuth]
|
50
|
IP-Address-Allocate
|
[RFC2882]
|
51
|
IP-Address-Release
|
[RFC2882]
|
250-253
|
Experimental Use
|
|
254
|
Reserved
|
|
255
|
Reserved
|
[RFC2865]
|
Заявление об интеллектуальной собственности
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF’s procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Благодарности
Спасибо Ignacio Goyret из Lucent, Allison Mankin из Lucent Bell Labs, Thomas Narten из IBM, Glen Zorn и Harald Alvestrand из Cisco за дискусии, относящиеся к этому документу.
Адреса авторов
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Перевод на русский язык
Николай Малых
Полное заявление авторских прав
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Подтверждение
Финансирование функций RFC Editor обеспечено IETF IASA8.
1Internet Assigned Numbers Authority.
2Remote Authentication Dial In User Service – аутентификация удаленных пользователей при доступе по коммутируемым телефонным линиям.
3Authentication, Authorization or Accounting – аутентификация, проверка полномочий или учет.
5Работа завершена и опубликована в RFC 3579. Прим. перев.
6В настоящее время Interim Accounting.
7Экспериментальный.
8Administrative Support Activity.
