Network Working Group                                           D. Mitton
Request for Comments: 2882                                Nortel Networks
Category: Informational                                         July 2000
        
Network Working Group                                           D. Mitton
Request for Comments: 2882                                Nortel Networks
Category: Informational                                         July 2000
        

Network Access Servers Requirements: Extended RADIUS Practices

网络访问服务器要求:扩展RADIUS实践

Status of this Memo

本备忘录的状况

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2000). All Rights Reserved.

版权所有(C)互联网协会(2000年)。版权所有。

Abstract

摘要

This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The purpose of this effort is to give examples that show the need for addressing and standardizing these types of ad-hoc functions. Since many of these features require a matching server support component, the ability to deploy and manage interoperable NAS and AAA server products is severely hindered.

本文档描述了超出RADIUS RFCs 21382139[1,2]范围的NAS产品中实施的当前实践。这项工作的目的是举例说明解决和标准化这些特殊功能类型的必要性。由于其中许多功能需要匹配的服务器支持组件,因此部署和管理可互操作的NAS和AAA服务器产品的能力受到严重阻碍。

These practices are documented here to show functions that are obviously desired in developing future AAA protocols for NAS deployment.

这里记录了这些实践,以展示在为NAS部署开发未来AAA协议时显然需要的功能。

Table of Contents

目录

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .  2
   1.1.  Disclaimers . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2.  Presentation  . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Attribute Usage . . . . . . . . . . . . . . . . . . . . . .  3
   2.1. Attribute Conflicts  . . . . . . . . . . . . . . . . . . .  4
   2.2. Attribute Value Conflicts  . . . . . . . . . . . . . . . .  4
   2.2.1 Vendor Specific Enumerations Proposal . . . . . . . . . .  4
   2.3   Vendor Specific Attribute Usage . . . . . . . . . . . . .  5
   2.3.1 VSAs in use by clients: . . . . . . . . . . . . . . . . .  5
   2.3.2 Clients that support multiple Vendors:  . . . . . . . . .  5
   3.  Attribute Data Types  . . . . . . . . . . . . . . . . . . .  6
   4.  New Messages  . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Additional Functions  . . . . . . . . . . . . . . . . . . .  7
   5.1 Password Change   . . . . . . . . . . . . . . . . . . . . .  8
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .  2
   1.1.  Disclaimers . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2.  Presentation  . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Attribute Usage . . . . . . . . . . . . . . . . . . . . . .  3
   2.1. Attribute Conflicts  . . . . . . . . . . . . . . . . . . .  4
   2.2. Attribute Value Conflicts  . . . . . . . . . . . . . . . .  4
   2.2.1 Vendor Specific Enumerations Proposal . . . . . . . . . .  4
   2.3   Vendor Specific Attribute Usage . . . . . . . . . . . . .  5
   2.3.1 VSAs in use by clients: . . . . . . . . . . . . . . . . .  5
   2.3.2 Clients that support multiple Vendors:  . . . . . . . . .  5
   3.  Attribute Data Types  . . . . . . . . . . . . . . . . . . .  6
   4.  New Messages  . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Additional Functions  . . . . . . . . . . . . . . . . . . .  7
   5.1 Password Change   . . . . . . . . . . . . . . . . . . . . .  8
        
   5.2 Authentication Modes  . . . . . . . . . . . . . . . . . . .  8
   5.3 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.4 Pseudo Users  . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Resource Management . . . . . . . . . . . . . . . . . . . .  9
   6.1 Managed Resources . . . . . . . . . . . . . . . . . . . . .  9
   6.2 Resource Management Messages  . . . . . . . . . . . . . . . 10
   6.3 Concurrent Logins . . . . . . . . . . . . . . . . . . . . . 10
   6.4 Authorization Changes . . . . . . . . . . . . . . . . . . . 11
   7. Policy Services  . . . . . . . . . . . . . . . . . . . . . . 11
   8. Accounting Extensions  . . . . . . . . . . . . . . . . . . . 12
   8.1 Auditing/Activity . . . . . . . . . . . . . . . . . . . . . 12
   9. Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . 12
   10. Security Considerations . . . . . . . . . . . . . . . . . . 13
   11. Implementation Documents  . . . . . . . . . . . . . . . . . 13
   11.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 13
   11.2. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 14
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . 14
   13. Author's Address  . . . . . . . . . . . . . . . . . . . . . 15
   14. Full Copyright Statement  . . . . . . . . . . . . . . . . . 16
        
   5.2 Authentication Modes  . . . . . . . . . . . . . . . . . . .  8
   5.3 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.4 Pseudo Users  . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Resource Management . . . . . . . . . . . . . . . . . . . .  9
   6.1 Managed Resources . . . . . . . . . . . . . . . . . . . . .  9
   6.2 Resource Management Messages  . . . . . . . . . . . . . . . 10
   6.3 Concurrent Logins . . . . . . . . . . . . . . . . . . . . . 10
   6.4 Authorization Changes . . . . . . . . . . . . . . . . . . . 11
   7. Policy Services  . . . . . . . . . . . . . . . . . . . . . . 11
   8. Accounting Extensions  . . . . . . . . . . . . . . . . . . . 12
   8.1 Auditing/Activity . . . . . . . . . . . . . . . . . . . . . 12
   9. Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . 12
   10. Security Considerations . . . . . . . . . . . . . . . . . . 13
   11. Implementation Documents  . . . . . . . . . . . . . . . . . 13
   11.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 13
   11.2. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 14
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . 14
   13. Author's Address  . . . . . . . . . . . . . . . . . . . . . 15
   14. Full Copyright Statement  . . . . . . . . . . . . . . . . . 16
        
1. Introduction
1. 介绍

The RADIUS Working Group was formed in 1995 to document the protocol of the same name, and was chartered to stay within a set of bounds for dial-in terminal servers. Unfortunately the real world of Network Access Servers (NASes) hasn't stayed that small and simple, and continues to evolve at an amazing rate.

RADIUS工作组成立于1995年,以记录同名协议,并被特许在拨入终端服务器的一组范围内。不幸的是,网络访问服务器(NASE)的现实世界并没有保持那么小和简单,而是继续以惊人的速度发展。

This document shows some of the current implementations on the market have already outstripped the capabilities of the RADIUS protocol. A quite a few features have been developed completely outside the protocol. These features use the RADIUS protocol structure and format, but employ operations and semantics well beyond the RFC documents.

本文档显示,目前市场上的一些实现已经超过了RADIUS协议的功能。相当多的功能完全在协议之外开发。这些特性使用RADIUS协议结构和格式,但使用的操作和语义远远超出RFC文档。

I learn of the details of these functions from reading industry manuals and often have to respond to them in competive bid specifications. As they become deployed in the field, they gather the force of de-facto standards.

我从阅读行业手册中了解到这些功能的详细信息,并经常在竞争性投标规范中对其作出响应。当他们部署到实地时,他们聚集了事实标准的力量。

Because they have been done outside scope of the RFCs, they are vendor specific, and introduce significant problems in offering an interoperable product.

因为它们是在RFC范围之外完成的,所以它们是特定于供应商的,并且在提供可互操作的产品时引入了重大问题。

1.1. Disclaimers
1.1. 免责声明

The data and numbers in this document have been gleaned from public sources and vendor documents along the way. Actual implementation of many these features and variation from the documentation has not been confirmed.

本文件中的数据和数字是从公共来源和供应商文件中收集的。许多这些特性的实际实现以及与文档的差异尚未得到确认。

This document is a snapshot of known practices at the time of writing. It is not intended to standardize these practices here, or keep this document current, beyond initial publication. While some detailed information is given, it is not the purpose of this document to directly or sufficiently describe the functions mentioned to the level of a complete functional specification.

本文档是撰写本文时已知实践的快照。本文件的目的不是在首次发布后使这些实践标准化,或使本文件保持最新。虽然给出了一些详细信息,但本文件的目的不是直接或充分地描述完整功能规范所提及的功能。

The author has not transcribed copyrighted material, and is not aware of whether any of these practices have of intellectual property restrictions.

作者没有转录受版权保护的材料,也不知道这些做法是否有知识产权限制。

Any numeric assignments or functional operations are subject to change by vendors without notice. I would appreciate any direct input, preferably first hand, from implementors.

任何数字分配或功能操作如有变更,供应商恕不另行通知。我将非常感谢实施者的直接投入,最好是第一手资料。

1.2. Presentation
1.2. 演示

Without any easy organization for the material, information is arranged in a simple taxonomy from bottom-up complexity:

在没有任何简单的材料组织的情况下,信息按照自下而上的简单分类法排列:

- Attribute Usage

- 属性用法

- Attribute Data Types

- 属性数据类型

- Message Codes

- 消息代码

- New Operations

- 新业务

2. Attribute Usage
2. 属性用法

The RADIUS RFCs define attribute type ranges and specific attribute definitions.

RADIUS RFC定义属性类型范围和特定属性定义。

- There are about 70 defined RADIUS attributes:

- 定义的半径属性大约有70个:

- Values 192-223 are reserved for experimental use

- 值192-223保留供实验使用

- Values 224-240 are reserved for implementation-specific use

- 值224-240保留用于实现特定用途

- Values 241-255 are reserved and should not be used.

- 值241-255为保留值,不应使用。

Attribute 26 was defined to be the Vendor Specific Attribute (VSA) with further internal structure to allow vendor expansion.

属性26被定义为供应商特定属性(VSA),具有进一步的内部结构以允许供应商扩展。

2.1. Attribute conflicts
2.1. 属性冲突

In practice attributes 92-255 are in use by a vendor. And another vendor also use attributes in the 90-104 range and conflicts with this usage.

实际上,供应商正在使用属性92-255。另一个供应商也使用90-104范围内的属性,并且与此用法冲突。

To deal with these issues, server vendors have added vendor specific parameters to their client database files. The administrator has to indicate the vendor type of NAS along with the client IP address and secret, so that the server can disambiguate the attribute usage.

为了解决这些问题,服务器供应商向其客户机数据库文件中添加了特定于供应商的参数。管理员必须指出NAS的供应商类型以及客户端IP地址和密码,以便服务器能够消除属性用法的歧义。

One server has a single large vendors file to describe the mapping all attributes to an internal format that retains the vendor id. Another server implementation uses multiple dictionaries, each indexed to a NAS and Vendor Model definition list.

一台服务器有一个大型供应商文件,用于描述将所有属性映射到保留供应商id的内部格式。另一台服务器实现使用多个字典,每个字典都索引到NAS和供应商模型定义列表。

2.2. Attribute Value Conflicts
2.2. 属性值冲突

Adding additional attributes may be more trouble than necessary for simple features. Often existing RADIUS attributes could be extended with additional values (particularly attributes that are enumerated choices). But in doing such there is no way to guarantee not conflicting with other vendor's extensions.

添加附加属性可能比简单功能所需的更麻烦。通常,可以使用附加值(特别是枚举选项的属性)扩展现有半径属性。但这样做无法保证与其他供应商的扩展不冲突。

2.2.1. Vendor Specific Enumerations proposal
2.2.1. 供应商特定的枚举建议

One proposed solution to this problem was Vendor Specific Enumerations (VSEs). That is to imbed the vendor's management ID in the numeric value (ala VSAs) which would to divide up the attribute value space. This technique has not seen any acceptance by the working group or other vendors, however, the vendor did accomplish the goal of not conflicting with working group additions or other vendor values.

针对这个问题提出的一个解决方案是特定于供应商的枚举(VSE)。也就是说,将供应商的管理ID嵌入数字值(ala-VSAs)中,以划分属性值空间。该技术未被工作组或其他供应商接受,但是,供应商确实实现了不与工作组新增内容或其他供应商价值相冲突的目标。

Example dictionary of VSE values:

VSE值字典示例:

VALUE Service-Type VSE-Authorize-Only 0x06300001

值服务类型VSE仅授权0x06300001

VALUE Acct-Status-Type VSE-User-Reject 0x06300001 VALUE Acct-Status-Type VSE-Call-Reject 0x06300002 VALUE Acct-Status-Type VSE-IPCP-Start 0x06300003 VALUE Acct-Status-Type VSE-IPXCP-Start 0x06300004 VALUE Acct-Status-Type VSE-ATCP-Start 0x06300005 VALUE Acct-Status-Type VSE-Accounting-Restart 0x06300006 VALUE Acct-Status-Type VSE-Accounting-Shutoff 0x06300007

价值账户状态类型VSE用户拒绝0x06300001价值账户状态类型VSE呼叫拒绝0x06300002价值账户状态类型VSE IPCP启动0x06300003价值账户状态类型VSE IPXCP启动0x06300004价值账户状态类型VSE ATCP启动0x06300005价值账户状态类型VSE会计重启0x06300006价值账户状态类型VSE会计关闭0x06300007

VALUE Acct-Status-Type VSE-Tunnel-Start 0x06300008 VALUE Acct-Status-Type VSE-Tunnel-Stop 0x06300009 VALUE Acct-Status-Type VSE-Tunnel-Reject 0x0630000a VALUE Acct-Status-Type VSE-Tunnel-Link-Start 0x0630000b VALUE Acct-Status-Type VSE-Tunnel-Link-Stop 0x0630000c VALUE Acct-Status-Type VSE-MP-Start 0x0630000d VALUE Acct-Status-Type VSE-MP-Stop 0x0630000e VALUE Acct-Status-Type VSE-Line-Seizure 0x0630000f VALUE Acct-Status-Type VSE-Rlogin-Start 0x06300010 VALUE Acct-Status-Type VSE-Rlogin-Stop 0x06300011

值帐户状态类型VSE隧道开始0x063000008值帐户状态类型VSE隧道停止0x063000009值帐户状态类型VSE隧道拒绝0x0630000a值帐户状态类型VSE隧道链路开始0x0630000b值帐户状态类型VSE隧道链路停止0x0630000c值帐户状态类型VSE MP开始0x0630000d值帐户状态类型VSE MP停止0x06300000E值账户状态类型VSE线路占用0x0630000f值账户状态类型VSE登录开始0x063000010值账户状态类型VSE登录停止0x06300011

2.3. Vendor Specific Attribute Usage
2.3. 特定于供应商的属性用法

Because attribute 26 Vendor Specific Attributes (VSAs) came late in the RADIUS working group development, there were some server implementations that were late to support them. Today, there are several leading implementations of clients that make extensive use of VSAs. What's unfortunate is that there is also several different formats of VSAs implemented. This is because the RFC suggested format does not support more than 256 attributes.

由于属性26供应商特定属性(VSA)在RADIUS工作组开发中出现较晚,因此有些服务器实现支持它们的时间较晚。今天,有几种领先的客户机实现广泛使用VSA。不幸的是,还实现了几种不同格式的VSA。这是因为RFC建议的格式不支持超过256个属性。

2.3.1. VSAs in use by some clients:

2.3.1. 某些客户端正在使用的VSA:

At the time this document was written, the following had be observed:

在编写本文件时,已遵守以下规定:

- Microsoft: several for MS-CHAP authentication support [9]

- Microsoft:支持MS-CHAP身份验证的几种方法[9]

- ACC: 42 [10]

- 行政协调会:42[10]

- Nortel(Bay): about 60 VSAs and 16 VSEs

- 北电(海湾):约60个VSA和16个VSE

- Nortel(Aptis): about 60 VSA: 20 1-byte, ~130 4-byte header. Aptis VSAs have shifted from a regular format to a 4-byte header format, due to the large number of attributes implemented.

- 北电(Aptis):大约60个VSA:20个1字节,约130个4字节头。由于实现了大量属性,Aptis VSA已从常规格式转变为4字节头格式。

- 3Com (USR): about 130 USR VSAs are different than the format suggested in RFC 2138. They have a 4 byte type field and have no internal length.

- 3Com(USR):大约130个USR VSA与RFC 2138中建议的格式不同。它们有一个4字节类型的字段,没有内部长度。

Some vendors that did not initially use VSAs, have shifted in later releases VSA usage as a configuration option.

一些最初未使用VSA的供应商在以后的版本中已将VSA的使用作为配置选项。

2.3.2. Clients that support Multiple Vendor Attributes
2.3.2. 支持多个供应商属性的客户端

Now that MS-CHAP RADIUS attributes have been published in RFC 2548 [9] as Microsoft VSA attributes, it will become typical that for NAS clients that support MS-CHAP authentication to process several

既然MS-CHAP RADIUS属性已在RFC 2548[9]中作为Microsoft VSA属性发布,那么对于支持MS-CHAP身份验证的NAS客户端来说,处理多个

different vendor VSA types. This has implications for RADIUS servers that filter or "prune" return attributes based on the vendor make/model of the NAS client.

不同的供应商VSA类型。这意味着RADIUS服务器会根据NAS客户端的供应商品牌/型号过滤或“删减”返回属性。

One NAS implementation can receive up to three different vendor specific attribute sets, but will only send attributes according to the "mode" that has been configured by the operator. This allows it to fit into environments where the customer has become dependent on a particular set of RADIUS attributes, and allows the NAS to "drop-in" without server attribute changes.

一个NAS实施最多可以接收三个不同的特定于供应商的属性集,但只能根据运营商配置的“模式”发送属性。这使它能够适应客户依赖于一组特定RADIUS属性的环境,并允许NAS“插入”,而无需更改服务器属性。

There is another NAS that supports 3 vendor attributes sets concurrently. That is, it will normally use a combination of different vendor VSAs in return profiles from the server. This was done to support a superset of competing vendor's extensions, as well as it's own, and include an extensions from a sister product.

另一个NAS同时支持3个供应商属性集。也就是说,它通常会在服务器的返回配置文件中使用不同供应商VSA的组合。这样做是为了支持竞争供应商的扩展超集,以及它自己的扩展超集,并包括来自姐妹产品的扩展。

3. Attribute Data Types
3. 属性数据类型

The base RFCs define only has 4 basic data types:

基本RFC定义只有4种基本数据类型:

- integer, 32 bit unsigned

- 整数,32位无符号

- string, 1-253 bytes, counted.

- 字符串,1-253字节,已计数。

- ipaddr, 32 bit IPv4

- ipaddr,32位IPv4

- date, 32 bit Unix format.

- 日期,32位Unix格式。

Since then, various variations have been added:

此后,增加了各种变化:

The tunnel authentication document [6] adds an optional compound "tag" byte to tunnel attributes. These are a single byte prepended to the data field in order to support sets of attributes to be returned. The byte value must be in the range 01-3F hex or it is considered to be data.

隧道身份验证文档[6]将可选的复合“标记”字节添加到隧道属性中。这些是数据字段前面的一个字节,用于支持要返回的属性集。字节值必须在01-3F十六进制范围内,否则视为数据。

Note that there is no native support for IPv6 addresses. In fact IPv6 support is missing in some fixed message components too.

请注意,本机不支持IPv6地址。事实上,某些固定消息组件中也缺少IPv6支持。

There have been special attribute types created within servers. For packet filters, the format called "abinary" was created. The user enters an ASCII string filter description in the user profile, but the server parses it into a binary string before passing it to the NAS. This lowers the complexity of the NAS parser. Also a "phonestring" server data type allows additional data type checking at the entry application.

在服务器中创建了一些特殊的属性类型。对于包过滤器,创建了名为“abinary”的格式。用户在用户配置文件中输入ASCII字符串筛选器描述,但服务器在将其传递给NAS之前将其解析为二进制字符串。这降低了NAS解析器的复杂性。此外,“phonestring”服务器数据类型允许在输入应用程序中进行额外的数据类型检查。

4. New Messages
4. 新消息

A number of new message types have been introduced by various parties over time. The base specification has 6, vendors have added 26.

随着时间的推移,各方引入了许多新的消息类型。基本规范有6个,供应商增加了26个。

These fall into a number of categories which are described in the next section below. Some of these messages are actually used between the RADIUS server and some other resource server, using a RADIUS-like protocol to implement new functions.

这些可分为若干类别,将在下一节中介绍。其中一些消息实际上在RADIUS服务器和其他资源服务器之间使用,使用类似RADIUS的协议来实现新功能。

6 Accounting Status (now Interim Accounting [5]) 7 Password Request 8 Password Ack 9 Password Reject 10 Accounting Message

6记帐状态(现在为临时记帐[5])7密码请求8密码确认9密码拒绝10记帐消息

21 Resource Free Request 22 Resource Free Response 23 Resource Query Request 24 Resource Query Response 25 Alternate Resource Reclaim Request 26 NAS Reboot Request 27 NAS Reboot Response

21资源空闲请求22资源空闲响应23资源查询请求24资源查询响应25备用资源回收请求26 NAS重新启动请求27 NAS重新启动响应

29 Next Passcode 30 New Pin 31 Terminate Session 32 Password Expired 33 Event Request 34 Event Response 40 Disconnect Request 41 Disconnect Ack 42 Disconnect Nak 43 Change Filters Request 44 Change Filters Ack 45 Change Filters Nak 50 IP Address Allocate 51 IP Address Release

29下一个密码30新针脚31终止会话32密码过期33事件请求34事件响应40断开请求41断开确认42断开Nak 43更改筛选器请求44更改筛选器Ack 45更改筛选器Nak 50 IP地址分配51 IP地址释放

5. Additional Functions
5. 附加功能

These are operations performed using RADIUS extensions and additional messages types.

这些是使用RADIUS扩展和其他消息类型执行的操作。

5.1. Password Change
5.1. 密码更改

Remotely requested password change operations were described and proposed, but rejected by the working group. None the less, the feature is still deployed in a number of products.

对远程请求的密码更改操作进行了描述和提议,但被工作组拒绝。尽管如此,该功能仍然部署在许多产品中。

Message types:

消息类型:

- Password Request - Password Ack or Reject

- 密码请求-密码确认或拒绝

5.2. Authentication Modes
5.2. 认证模式

Additional message types have been added to negotiate passcode changes for token card servers.

已添加其他消息类型,以协商令牌卡服务器的密码更改。

- Next Passcode - New PIN - Password Expired

- 下一个密码-新PIN-密码已过期

They allow the NAS or RADIUS server negotiate passcode changes with an external security server.

它们允许NAS或RADIUS服务器与外部安全服务器协商密码更改。

5.3. Menus
5.3. 菜单

At least two vendors have built menuing interaction systems for use with terminal dial-ins.

至少有两家供应商已经建立了菜单交互系统,用于终端拨号。

One implementation uses the Reply-Message string as the menu text to be displayed, and the State attribute to keep track of the place in the menu. The menu is displayed using the Access-Challenge message. The response is encoded in the User-Password field like an ordinary challenge sequence would.

一个实现使用回复消息字符串作为要显示的菜单文本,使用状态属性跟踪菜单中的位置。使用访问质询消息显示菜单。响应像普通质询序列一样编码在用户密码字段中。

Some RADIUS clients have problems with this because they cannot handle long or multiple Reply-Message attributes that may have embedded carriage returns and line-feeds. The new Echo attribute should also control echo behavior on the menu response. Use of the State attribute to keep track of a Challenge sequence is also standard behavior.

一些RADIUS客户端在这方面存在问题,因为它们无法处理可能具有嵌入回车符和换行符的长或多个回复消息属性。新的Echo属性还应控制菜单响应上的Echo行为。使用State属性跟踪质询序列也是标准行为。

Another implementation uses two vendor attributes (VSA-Menu-Item, and VSA-Menu-Selector as well as VSA-Third-Prompt) to convey this information. This implementation is vendor specific.

另一个实现使用两个供应商属性(VSA菜单项、VSA菜单选择器以及VSA第三个提示符)来传递此信息。此实现是特定于供应商的。

5.4. Pseudo Users
5.4. 伪用户

One client implementation takes advantage of your vanilla RADIUS server's ability to be used as a remote database server. By using some well-known, implementation specific, strings for Username and Password attributes, the NAS can request information from the server, such as: Static IP routes, Static IPX routes, or the Message of the Day.

一个客户端实现利用了香草RADIUS服务器作为远程数据库服务器的能力。通过使用一些众所周知的、特定于实现的用户名和密码属性字符串,NAS可以从服务器请求信息,例如:静态IP路由、静态IPX路由或当日消息。

These are called pseudo-user requests, because they use a user entry with this manufactured name, for purposes other than authentication.

这些被称为伪用户请求,因为它们使用具有此制造名称的用户条目,用于身份验证以外的目的。

Another client also uses a pseudo-user technique for resolving unknown Filter-ID(11) values. An Access-Request message is sent to the RADIUS server with the Filter-ID as the Username value, the password is a known string, and the Service-Type is VSE-Authorization-Only. The response must also be of the same Service-Type, or the response will be ignored. The responding profile should contain the IP-Filter VSA attributes that will define the desired filter.

另一个客户端还使用伪用户技术来解析未知的筛选器ID(11)值。将访问请求消息发送到RADIUS服务器,筛选器ID作为用户名值,密码为已知字符串,服务类型仅为VSE授权。响应也必须是相同的服务类型,否则将忽略响应。响应配置文件应包含定义所需筛选器的IP筛选器VSA属性。

It should be noticed that pseudo-user profiles could be a security problem if a specific or operationally invalid Service-Type is not attached to the profile. The client should test for this returned value, to prevent normal dial-in users from gaining access via this profile.

应该注意的是,如果特定的或操作上无效的服务类型未附加到配置文件,则伪用户配置文件可能是一个安全问题。客户端应测试此返回值,以防止普通拨入用户通过此配置文件获得访问权限。

6. Resource Management
6. 资源管理

Authorized sessions may need to be allocated additional dynamic resources in order to perform their services. The most typical is IP addresses. The allocation may want to be delayed until needed or coordinated on a scale independent of the RADIUS server. Additional messages may be used to allocate and free these resources. The RADIUS server may proxy these requests to another server.

授权会话可能需要分配额外的动态资源以执行其服务。最典型的是IP地址。分配可能需要延迟到需要时,或在独立于RADIUS服务器的范围内进行协调。其他消息可用于分配和释放这些资源。RADIUS服务器可以将这些请求代理给其他服务器。

Examples: Certain servers can allocate addresses local to the NAS or use an outboard address server. Other servers have an internal address pool capability, which will fill in the Framed-IP-Address attribute with an assigned value based on pool selected.

示例:某些服务器可以为NAS分配本地地址或使用外部地址服务器。其他服务器具有内部地址池功能,它将根据所选的池使用指定值填充框架IP地址属性。

6.1. Managed Resources:

6.1. 管理资源:

Resources managed include: IP Addresses, Concurrent Logins, Dial-in Port allocation policies, Tunnel limits and load distribution.

管理的资源包括:IP地址、并发登录、拨入端口分配策略、隧道限制和负载分配。

There are several different types of implementation techniques:

有几种不同类型的实现技术:

- Explicit request/free resource requests - Monitor usage with deamons watching the state - Explicit messages to a state deamon - Monitor Accounting messages for state changes

- 显式请求/空闲资源请求-监视使用情况,由执事监视状态-向状态执事发送显式消息-监视状态更改的记帐消息

6.2. Resource Management Messages
6.2. 资源管理消息

Messages used for resource management

用于资源管理的消息

- IP Address Allocate - IP Address Release

- IP地址分配-IP地址释放

- Resource Request - Resource Response - Resource Free Request - Resource Free Response - Resource Reclaim Request - NAS Reboot Request/Response

- 资源请求-资源响应-资源空闲请求-资源空闲响应-资源回收请求-NAS重新启动请求/响应

These messages are used to allocate and free resources for a NAS from a centralized server. These mechanisms allows the service provider better administrative control than some automated LAN services, which don't have policy inputs or controls.

这些消息用于从集中式服务器为NAS分配和释放资源。与一些没有策略输入或控制的自动化LAN服务相比,这些机制允许服务提供商进行更好的管理控制。

6.3. Concurrent Logins
6.3. 并发登录

The RADIUS protocol was designed to allow stateless servers. That is, servers that don't know the status of the active sessions. However, it is very important for many service providers to keep track of how many sessions a given user may have open, and accordingly disallow access.

RADIUS协议旨在允许无状态服务器。也就是说,服务器不知道活动会话的状态。然而,对于许多服务提供商来说,跟踪给定用户可能打开的会话数量并相应地禁止访问是非常重要的。

There are several different techniques used to implement login limits on a RADIUS environment. Some vendors have build NAS monitoring tools either into their RADIUS servers, either directly or as auxiliary deamons, that can check the session status of the controlled NASes by SNMP or proprietary methods.

有几种不同的技术用于在RADIUS环境中实现登录限制。一些供应商已经在其RADIUS服务器中构建了NAS监控工具(直接或作为辅助执事),可以通过SNMP或专有方法检查受控NASE的会话状态。

Other vendors monitor the RADIUS accesses and accounting messages and derive state information from the requests. This monitoring is not as reliable as directly auditing the NAS, but it is also less vendor specific, and can work with any RADIUS NAS, provided it sends both streams to the same server.

其他供应商监控RADIUS访问和记帐消息,并从请求中获取状态信息。这种监视不如直接审计NAS可靠,但它也不太特定于供应商,可以与任何RADIUS NAS一起工作,只要它将两个流发送到同一服务器。

Some of the approaches used:

使用的一些方法:

- SNMP commands - Telnet monitor deamon - Accounting monitor

- SNMP命令-Telnet监视器deamon-记帐监视器

6.4. Authorization Changes:

6.4. 授权更改:

To implement an active changes to a running session, such as filter changes or timeout and disconnect, at least one vendor has added a RADIUS "server" to his NAS. This server accepts messages sent from an application in the network, and upon matching some session information, will perform such operations.

要对正在运行的会话实施活动更改,例如筛选器更改或超时和断开连接,至少有一家供应商已将RADIUS“服务器”添加到其NAS中。此服务器接受从网络中的应用程序发送的消息,并在匹配某些会话信息后执行此类操作。

Messages sent from Server to NAS

从服务器发送到NAS的消息

- Change Filter Request - Change Filter Ack / Nak - Disconnect Request - Disconnect Response

- 更改过滤器请求-更改过滤器确认/Nak-断开连接请求-断开连接响应

Filters are used to limit the access the user has to the network by restricting the systems and protocols he can send packets to. Upon fulfilling some registration with an authorization server, the service provider may wish to remove those restrictions, or disconnect the user.

过滤器用于通过限制用户可以向其发送数据包的系统和协议来限制用户对网络的访问。在向授权服务器完成某些注册后,服务提供商可能希望删除这些限制,或断开用户连接。

7. Policy Services
7. 政策服务

Some vendors have implemented policy servers using RADIUS as the control protocol. Two prominent Policy Managers act as RADIUS proxy filters and use RADIUS messages to deny access to new sessions that exceed active policy limits.

一些供应商已经使用RADIUS作为控制协议实现了策略服务器。两个著名的策略管理器充当RADIUS代理筛选器,并使用RADIUS消息拒绝访问超出活动策略限制的新会话。

One implementation behaves like a RADIUS proxy server, but with a policy process governing it's forward decisions. Typically a pre-authentication message (like the new RADIUS draft Service-Type = CallCheck) is emitted by the NAS upon call arrival. This message will contain only the Dialed-Number information in the Username field. The server receives the Access-Request messages and processes them against it's knowledge of the network state and the provisioned policies.

一个实现的行为类似于RADIUS代理服务器,但有一个策略过程来管理其转发决策。通常,在呼叫到达时,NAS会发出预验证消息(如新的RADIUS草稿服务类型=CallCheck)。此消息在用户名字段中仅包含已拨号码信息。服务器接收访问请求消息,并根据其对网络状态和配置策略的了解来处理这些消息。

An Access-Accept will be returned to the system to accept the call, and many also contain dynamic policy information and Virtual POP specific default parameters. When the real PPP authentication is engaged, the proxy will forwards the Access-Request to a RADIUS server, if this session was approved at pre-auth. It can also process Access-Requests that were not preceded by a pre-auth exchange, and use the Username field for information about the

Access Accept将返回给系统以接受调用,其中许多还包含动态策略信息和特定于虚拟POP的默认参数。当实际PPP身份验证生效时,如果此会话在预身份验证时获得批准,则代理将把访问请求转发给RADIUS服务器。它还可以处理未经过预授权交换的访问请求,并使用用户名字段获取有关预授权交换的信息

desired realm, in it's policy evaluation.

所需领域,在其策略评估中。

The other implementation performs a similar operations. It uses VSAs in the Access-Request to distinguish pre-authentication message types.

另一个实现执行类似的操作。它在访问请求中使用VSA来区分预验证消息类型。

8. Accounting Extensions
8. 会计扩展

Traditional Accounting only records session starts and stops which is pretty boring. Additional session information reporting can be added easily which gives a better picture of operation in use as they happen. Some event types are listed below.

传统的会计只记录会话的开始和停止,这很无聊。可以轻松添加额外的会话信息报告,从而更好地了解正在使用的操作。下面列出了一些事件类型。

8.1. Auditing/Activity
8.1. 审计/活动

- Call or Modem Starts, Stops - Tunnel Starts, Stops - Tunnel Link Starts & Stops - Admin changes

- 呼叫或调制解调器启动、停止-隧道启动、停止-隧道链路启动和停止-管理员更改

These events if monitored by a stateful server can be used to gather information about the usage of the network on a user/session basis. Information about when a particular user entered the network is more relevant to network service management than attempting track backwards from low level IP address flows. Useful information about port usage across a range of NASes allows service provider to quickly find problem areas or users.

这些事件如果由有状态服务器监控,则可用于收集有关用户/会话网络使用情况的信息。有关特定用户何时进入网络的信息与网络服务管理更相关,而不是试图从低级IP地址流向后跟踪。关于一系列NASE的端口使用情况的有用信息允许服务提供商快速找到问题区域或用户。

Information about call failures, successes, and quality are also deemed important many service providers.

许多服务提供商也认为有关呼叫失败、成功和质量的信息很重要。

Extending RADIUS accounting is easy, it's surprising that more implementations have not been made in this area.

扩展RADIUS记帐很容易,但令人惊讶的是,在这个领域还没有更多的实现。

9. Conclusions
9. 结论

In real life RADIUS Servers are becoming rather complex software implementations. They are often brokering authentication and authorization to other authorities or repositories. Variants of RADIUS protocol is often used as glue protocol for these type of solutions.

在现实生活中,RADIUS服务器的软件实现变得相当复杂。他们通常是代理身份验证和授权给其他机构或存储库。RADIUS协议的变体通常用作此类解决方案的粘合协议。

Some of the solutions are kludges that could be cleaned up by better underlying services.

一些解决方案是可以通过更好的底层服务来解决的难题。

What this means to the implementor is that RADIUS as the RFCs describe it is becoming less relevant. Many additional features require matching client and server processing message processing.

对实施者来说,这意味着RFC描述的RADIUS变得越来越不相关。许多附加功能需要匹配的客户端和服务器处理消息处理。

Without standardization of these functions we don't have much interoperability in the field and much effort is spent in reverse engineering and reaction to unknown areas.

如果没有这些功能的标准化,我们在该领域就没有太多的互操作性,并且在逆向工程和对未知领域的反应上花费了太多的精力。

This memo is not a complete survey by any means. It is a representative summary of practices that I am aware of at the time of writing. I still appreciate input from vendors or users on practices and details known, and particularly any reference material you can pass me.

这份备忘录无论如何都不是一份完整的调查报告。这是我在撰写本文时所了解的实践的代表性总结。我仍然非常感谢供应商或用户对实践和已知细节的投入,特别是您可以传递给我的任何参考资料。

10. Security Considerations
10. 安全考虑

This document documents known practices, and does not propose any particular new protocols. Extensions to RADIUS protocols create new security implications because of their functions go beyond those considered in the RFCs. Some of these include:

本文件记录了已知的实践,并没有提出任何特定的新协议。RADIUS协议的扩展产生了新的安全影响,因为它们的功能超出了RFCs中考虑的功能。其中包括:

- The ability to change passwords via a RADIUS exchange was deliberately left out of the protocol by the working group, because of security concerns. - The Pseudo-User profiles and the Call-Check operation may allow unintended access if static and well-know account names and passwords are allowed to be used by regular interactive accounts. - Resource Management operations must be protected from denial of service attacks. - Client side authorization change exchanges need to be secured from attacks that could disconnect or restrict user services.

- 出于安全考虑,工作组故意将通过RADIUS交换更改密码的能力排除在协议之外。-如果常规交互帐户允许使用静态和众所周知的帐户名和密码,则伪用户配置文件和呼叫检查操作可能允许意外访问。-必须保护资源管理操作免受拒绝服务攻击。-客户端授权更改交换需要防止可能断开或限制用户服务的攻击。

11. Implementation Documents
11. 执行文件

Information about the following implementations can be obtained from the respective owners. Most listed are available from the manufacturer's web site.

有关以下实现的信息可以从各自的所有者处获得。大多数列表可从制造商的网站获得。

11.1. Clients:

11.1. 客户:

- 3Com(USR) Total Control Hub - Ericsson(ACC) Tigris draft-ilgun-radius-accvsa-01.txt, Dec 1998 - Lucent(Ascend) MAX TNT - Lucent(Livingston) Portmaster - Nortel(Aptis) CVX 1800 - Nortel(Bay Networks) Versalar 5399/8000 Remote Access Controller - Intel(Shiva)

- 3Com(USR)总控中心-爱立信(ACC)底格里斯草稿-ilgun-radius-accvsa-01.txt,1998年12月-朗讯(Ascend)MAX TNT-朗讯(利文斯顿)端口主管-北电(Aptis)CVX 1800-北电(海湾网络)Versalar 5399/8000远程访问控制器-英特尔(Shiva)

11.2. Servers:

11.2. 服务器:

- Ericsson(ACC) Virtual Port Server Manager - Funk Steel-Belted RADIUS - Intel(Shiva) Access Manager - Lucent(Ascend) Access Control - Lucent(Ascend) NavisAccess - Lucent(Ascend) Modified Livingston 1.16 - Lucent(Livingston) V2.01 - Lucent(Livingston) ABM - Lucent Port Authority - MERIT AAA Servers - Nortel(Bay Networks) BaySecure Access Control - Nortel Preside Radius - Nortel CVX Policy Manager

- 爱立信(ACC)虚拟端口服务器管理器-芬克钢带半径-英特尔(Shiva)访问管理器-朗讯(Ascend)访问控制-朗讯(Ascend)NavisAccess-朗讯(Ascend)修改版利文斯顿1.16-朗讯(利文斯顿)V2.01-朗讯(利文斯顿)ABM-朗讯港务局-美德AAA服务器-北电(海湾网络)BaySecure访问控制-北电Preside Radius-北电CVX策略管理器

12. References
12. 工具书类

[1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.

[1] Rigney,C.,Rubens,A.,Simpson,W.和S.Willens,“远程认证拨入用户服务(RADIUS)”,RFC 21381997年4月。

[2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.

[2] 里格尼,C.,“半径会计”,RFC 21391997年4月。

[3] Rigney, C., Willens, S., Ruebens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.

[3] Rigney,C.,Willens,S.,Ruebens,A.和W.Simpson,“远程认证拨入用户服务(RADIUS)”,RFC 28652000年6月。

[4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[4] 里格尼,C.,“半径会计”,RFC 28662000年6月。

[5] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.

[5] 里格尼,C.,威拉斯,W.和P.卡尔霍恩,“半径延伸”,RFC 28692000年6月。

[6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.

[6] Zorn,G.,Leifer,D.,Rubens,A.,Shriver,J.,Holdrege,M.和I.Goyret,“隧道协议支持的半径属性”,RFC 28682000年6月。

[7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.

[7] Zorn,G.,Aboba,B.和D.Mitton,“隧道协议支持的半径计算修改”,RFC 2867,2000年6月。

[8] Aboba, B. and G. Zorn, "Implementation of L2TP Compulsory Tunneling via RADIUS", RFC 2809, April 2000.

[8] Aboba,B.和G.Zorn,“通过半径实施L2TP强制隧道”,RFC 2809,2000年4月。

[9] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.

[9] Zorn,G.“微软供应商特定半径属性”,RFC 2548,1999年3月。

[10] Ilgun, K., "RADIUS Vendor Specific Attributes for ACC/Ericsson Datacom Access", Work in Progress.

[10] Ilgun,K.,“ACC/Ericsson数据通信访问的RADIUS供应商特定属性”,正在进行中。

13. Author's Address
13. 作者地址

David Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821

David Mitton Nortel Networks马萨诸塞州比尔里卡科技园大道880号01821

Phone: 978-288-4570 EMail: dmitton@nortelnetworks.com

电话:978-288-4570电子邮件:dmitton@nortelnetworks.com

14. Full Copyright Statement
14. 完整版权声明

Copyright (C) The Internet Society (2000). All Rights Reserved.

版权所有(C)互联网协会(2000年)。版权所有。

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 assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

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.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。