2004-08-18
修订历史 | ||
---|---|---|
修订 1.0 | 2004-10-18 | 修订者:LKS |
初始版本,由 TLDP 审阅。 | ||
修订 0.2b | 2004-10-13 | 修订者:LKS |
各种更新。感谢 Rick Moen <rick (at) linuxmafia com> 的语言审阅。 | ||
修订 0.0 | 2004-07-23 | 修订者:LKS |
初始草稿。 |
本文档描述了设置和使用 IEEE 802.1X 基于端口的网络访问控制 的软件和步骤,使用 Xsupplicant 作为 Supplicant,FreeRADIUS 作为后端身份验证服务器。
本文档描述了设置和使用 802.1X:基于端口的网络访问控制 的软件和步骤,使用 Xsupplicant 以及 PEAP (PEAP/MS-CHAPv2) 作为身份验证方法,FreeRADIUS 作为后端身份验证服务器。
如果首选 PEAP 以外的其他身份验证机制,例如 EAP-TLS 或 EAP-TTLS,则只需更改少量配置选项。Windows XP SP1/Windows 2000 SP3 也支持 PEAP/MS-CHAPv2。
802.1X-2001 标准规定
“基于端口的网络访问控制利用 IEEE 802 LAN 基础设施的物理访问特性,以便提供一种身份验证和授权连接到具有点对点连接特性的 LAN 端口的设备,并在身份验证和授权失败的情况下阻止访问该端口的方法。在这种情况下,端口是连接到 LAN 基础设施的单个连接点。” --- 802.1X-2001,第 1 页。
图 802.1X:无线节点必须经过身份验证才能访问其他 LAN 资源。
当新的无线节点 (WN) 请求访问 LAN 资源时,接入点 (AP) 会询问 WN 的身份。在 WN 通过身份验证之前,不允许除 EAP 之外的其他流量(“端口”已关闭)。
请求身份验证的无线节点通常称为 Supplicant,尽管更准确地说,无线节点包含 Supplicant。Supplicant 负责响应 Authenticator 数据,这些数据将建立其凭据。接入点也是如此;Authenticator 不是接入点。相反,接入点包含 Authenticator。Authenticator 甚至不需要在接入点中;它可以是外部组件。
EAP 是用于身份验证的协议,最初用于拨号 PPP。身份是用户名,并且使用 PAP 或 CHAP 身份验证 [RFC1994] 来检查用户的密码。由于身份以明文形式发送(未加密),恶意嗅探器可能会获悉用户的身份。因此,使用 “身份隐藏”;在加密的 TLS 隧道建立之前,不会发送真实身份。
发送身份后,身份验证过程开始。Supplicant 和 Authenticator 之间使用的协议是 EAP,或者更正确地说是 LAN 上 EAP 封装 (EAPOL)。Authenticator 将 EAP 消息重新封装为 RADIUS 格式,并将其传递给身份验证服务器。
在身份验证期间,Authenticator 仅在 Supplicant 和身份验证服务器之间中继数据包。当身份验证过程完成时,身份验证服务器会发送成功消息(如果身份验证失败,则发送失败消息)。然后,Authenticator 为 Supplicant 打开“端口”。
成功身份验证后,Supplicant 将被授予访问其他 LAN 资源/互联网的权限。
有关说明,请参见图 802.1X。
为什么称为“基于端口”的身份验证?Authenticator 处理受控端口和非受控端口。受控端口和非受控端口都是逻辑实体(虚拟端口),但使用与 LAN 的相同物理连接(相同的连接点)。
图 端口:受控端口的授权状态。
在身份验证之前,只有非受控端口是“打开的”。唯一允许的流量是 EAPOL;请参见图 端口上的 Authenticator 系统 1。在 Supplicant 通过身份验证后,受控端口将打开,并授予访问其他 LAN 资源的权限;请参见图 端口上的 Authenticator 系统 2。
802.1X 在新的 IEEE 无线标准 802.11i 中起着重要作用。
有线等效保密 (WEP) 是原始 802.11 标准的一部分,应提供机密性。不幸的是,WEP 设计不良且易于破解。没有身份验证机制,只有一种弱形式的访问控制(必须具有共享密钥才能通信)。在此处阅读更多信息 here。
为了响应 WEP 漏洞,IEEE 提出了一个新的无线安全标准,名为 802.11i。802.1X 在这个新标准中起着重要作用。
新的安全标准 802.11i 于 2004 年 6 月获得批准,修复了所有 WEP 弱点。它分为三个主要类别
临时密钥完整性协议 (TKIP) 是一种短期解决方案,可修复所有 WEP 弱点。TKIP 可以与旧的 802.11 设备一起使用(在驱动程序/固件升级后),并提供完整性和机密性。
带有 CBC-MAC 协议的计数器模式 (CCMP) [RFC2610] 是一种从头开始设计的新协议。它使用 AES [FIPS 197] 作为其加密算法,并且由于它比 RC4(在 WEP 和 TKIP 中使用)更占用 CPU 资源,因此可能需要新的 802.11 硬件。某些驱动程序可以在软件中实现 CCMP。CCMP 提供完整性和机密性。
802.1X 基于端口的网络访问控制:无论是使用 TKIP 还是 CCMP,802.1X 都用于身份验证。
此外,可以使用一种称为 “无线鲁棒身份验证协议” (WRAP) 的可选加密方法来代替 CCMP。WRAP 是最初基于 AES 的 802.11i 提案,但由于受到产权负担的困扰而被 CCMP 取代。WRAP 支持是可选的,但 CCMP 支持在 802.11i 中是强制性的。
802.11i 还具有扩展的密钥派生/管理,如下所述。
为了使用加密和完整性算法强制执行安全策略,必须获取密钥。幸运的是,802.11i 实现了密钥派生/管理方案。请参见图 KM。
图 KM:802.11i 中的密钥管理和分发。
当 Supplicant (WN) 和身份验证服务器 (AS) 进行身份验证时,AS 发送的最后一个消息之一(假设身份验证成功)是主密钥 (MK)。发送后,MK 仅 WN 和 AS 知道。MK 绑定到 WN 和 AS 之间的此会话。
WN 和 AS 都从主密钥派生出一个新密钥,称为成对主密钥 (PMK)。
然后,PMK 从 AS 移动到 Authenticator (AP)。只有 WN 和 AS 才能派生 PMK,否则 AP 可以代替 AS 做出访问控制决策。PMK 是一个新鲜的对称密钥,绑定到 WN 和 AP 之间的此会话。
PMK 和 4 次握手用于在 WN 和 AP 之间派生、绑定和验证成对瞬时密钥 (PTK)。PTK 是操作密钥的集合
密钥确认密钥 (KCK),顾名思义,用于证明拥有 PMK 并将 PMK 绑定到 AP。
密钥加密密钥 (KEK) 用于分发组瞬时密钥 (GTK)。如下所述。
临时密钥 1 和 2 (TK1/TK2) 用于加密。TK1 和 TK2 的用法特定于密码套件。
有关成对密钥层次结构的概述,请参见图 PKH。
然后,KEK 和 4 次组握手用于将组瞬时密钥 (GTK) 从 AP 发送到 WN。GTK 是连接到同一 Authenticator 的所有 Supplicant 之间的共享密钥,用于保护多播/广播流量。
图 PKH:成对密钥层次结构
对于小型办公室/家庭办公室 (SOHO)、ad-hoc 网络或家庭使用,可以使用预共享密钥 (PSK)。使用 PSK 时,整个 802.1X 身份验证过程将被省略。这也称为 “WPA Personal” (WPA-PSK),而使用 EAP(和 RADIUS)的 WPA 称为 “WPA Enterprise” 或仅称为 “WPA”。
256 位 PSK 是使用 [RFC2898] 中的 PBKDFv2 从给定密码生成的,并用作上述密钥管理方案中描述的主密钥 (MK)。它可以是整个网络的一个 PSK(不安全),也可以是每个 Supplicant 一个 PSK(更安全)。
行业没有时间等到 802.11i 标准完成。他们现在就想解决 WEP 问题!Wi-Fi 联盟 感受到了压力,拍摄了该标准的“快照”(基于草案 3),并将其称为Wi-Fi 保护访问 (WPA)。一项要求是现有 802.11 设备可以与 WPA 一起使用,因此 WPA 基本上是 TKIP + 802.1X。
WPA 不是长期的解决方案。要获得强大的安全网络 (RSN),硬件必须支持并使用 CCMP。RSN 基本上是 CCMP + 802.1X。
使用 TKIP 而不是 CCMP 的 RSN 也称为过渡安全网络 (TSN)。RSN 也可能称为 WPA2,这样市场就不会感到困惑。
困惑吗?
基本上
TSN = TKIP + 802.1X = WPA(1)
RSN = CCMP + 802.1X = WPA2
可扩展身份验证协议 (EAP) [RFC 3748] 只是针对身份验证优化的传输协议,而不是身份验证方法本身
“[EAP 是] 一个支持多种身份验证方法的身份验证框架。EAP 通常直接在数据链路层(如点对点协议 (PPP) 或 IEEE 802)上运行,而无需 IP。EAP 提供对重复消除和重传的自身支持,但依赖于较低层排序保证。EAP 本身不支持分片;但是,各个 EAP 方法可以支持此功能。” --- RFC 3748,第 3 页
由于 802.1X 使用 EAP,因此可以添加多种不同的身份验证方案,包括智能卡、Kerberos、公钥、一次性密码等。
下面列出了一些最常用的 EAP 身份验证机制。可在 IANA 找到已注册 EAP 身份验证类型的完整列表:http://www.iana.org/assignments/eap-numbers。
![]() | 并非所有身份验证机制都被认为是安全的! |
EAP-MD5: MD5 质询需要用户名/密码,并且等效于 PPP CHAP 协议 [RFC1994]。此方法不提供字典攻击抵抗、相互身份验证或密钥派生,因此在无线身份验证环境中几乎没有用处。
轻型 EAP (LEAP): 用户名/密码组合被发送到身份验证服务器 (RADIUS) 进行身份验证。Leap 是 Cisco 开发的专有协议,不被认为是安全的。Cisco 正在逐步淘汰 LEAP,转而支持 PEAP。可以在 here 找到最接近已发布标准的资料。
EAP-TLS: 在 Supplicant 和身份验证服务器之间的 EAP 中创建 TLS 会话。服务器和客户端都需要有效的 (x509) 证书,因此需要 PKI。此方法提供双向身份验证。EAP-TLS 在 [RFC2716] 中进行了描述。
EAP-TTLS: 设置加密的 TLS 隧道,用于安全传输身份验证数据。在 TLS 隧道内,可以使用(任何)其他身份验证方法。由 Funk Software 和 Meetinghouse 开发,目前是 IETF 草案。
受保护的 EAP (PEAP): 与 EAP-TTLS 一样,使用加密的 TLS 隧道。EAP-TTLS 和 EAP-PEAP 的 Supplicant 证书是可选的,但服务器 (AS) 证书是必需的。由 Microsoft、Cisco 和 RSA Security 开发,目前是 IETF 草案。
EAP-MSCHAPv2: 需要用户名/密码,基本上是 MS-CHAP-v2 的 EAP 封装 [RFC2759]。通常在 PEAP 加密隧道内使用。由 Microsoft 开发,目前是 IETF 草案。
远程身份验证拨入用户服务 (RADIUS) 在 [RFC2865](及其相关规范)中定义,主要由 ISP 使用,他们在用户获得授权使用 ISP 网络之前对用户名和密码进行身份验证。
802.1X 没有指定必须存在哪种后端身份验证服务器,但 RADIUS 是 802.1X 中使用的“事实上的”后端身份验证服务器。
可用的 AAA 协议不多,但 RADIUS 和 DIAMETER [RFC3588](包括其扩展)都符合完整的 AAA 支持。AAA 代表身份验证、授权和计费(IETF 的 AAA 工作组)。
![]() | 必须安装 OpenSSL 才能使用 EAP-TLS、EAP-TTLS 或 PEAP! |
使用 EAP-TLS 时,身份验证服务器和所有 Supplicant(客户端)都需要证书 [RFC2459]。使用 EAP-TTLS 或 PEAP 时,只有身份验证服务器需要证书;Supplicant 证书是可选的。
您可以从本地证书颁发机构 (CA) 获取证书。如果没有可用的本地 CA,则可以使用 OpenSSL 生成自签名证书。
FreeRADIUS 源代码中包含一些用于生成自签名证书的帮助程序脚本。这些脚本位于scripts/FreeRADIUS 源代码附带的文件夹中
CA.all是一个 shell 脚本,它根据它提出的一些问题生成证书。CA.certs根据脚本开头预定义的信息以非交互方式生成证书。
![]() | 脚本使用一个名为CA.pl的 Perl 脚本,该脚本包含在 OpenSSL 中。中此 Perl 脚本的路径CA.all和CA.certs可能需要更改才能使其工作。 |
![]() | 有关如何生成自己的证书的更多信息,请参见 SSL 证书 HOWTO。 |
FreeRADIUS 是一个完全 GPL 许可的 RADIUS 服务器实现。它支持广泛的身份验证机制,但本文档中的示例使用 PEAP。
安装 FreeRADIUS
转到 FreeRADIUS 站点 http://www.freeradius.org/,并下载最新版本。
# cd /usr/local/src # wget ftp://ftp.freeradius.org/pub/radius/freeradius-1.0.0.tar.gz # tar zxfv freeradius-1.0.0.tar.gz # cd freeradius-1.0.0 |
配置、make 和 install
# ./configure # make # make install |
您可以将选项传递给 configure。使用 ./configure --help 或阅读 README 文件,以获取更多信息。
二进制文件安装在/usr/local/bin和/usr/local/sbin。配置文件位于/usr/local/etc/raddb.
如果出现问题,请检查INSTALL和README源代码中包含的文件。RADIUS FAQ 也包含有价值的信息。
FreeRADIUS 具有一个庞大而强大的配置文件。它太大了,已被拆分为几个较小的文件,这些文件只是 “包含”在主文件中radius.conf文件中。
有很多方法可以使用和设置 FreeRADIUS 来执行您想要的操作:即,从 LDAP、SQL、PDC、Kerberos 等获取用户信息。在本文档中,使用了来自纯文本文件的用户信息,users。
![]() | 配置文件已进行了详尽的注释,如果这还不够,则doc/源代码附带的文件夹包含其他信息。 |
配置 FreeRADIUS
配置文件可以在/usr/local/etc/raddb/
# cd /usr/local/etc/raddb/ |
下找到打开主配置文件radiusd.conf
,并阅读注释!在加密的 PEAP 隧道内,使用了 MS-CHAPv2 身份验证机制。
# under MODULES, make sure mschap is uncommented! mschap { # authtype value, if present, will be used # to overwrite (or add) Auth-Type during # authorization. Normally, should be MS-CHAP authtype = MS-CHAP # if use_mppe is not set to no, mschap will # add MS-CHAP-MPPE-Keys for MS-CHAPv1 and # MS-MPPE-Recv-Key/MS-MPPE-Send-Key for MS-CHAPv2 # use_mppe = yes # if mppe is enabled, require_encryption makes # encryption moderate # require_encryption = yes # require_strong always requires 128 bit key # encryption # require_strong = yes authtype = MS-CHAP # The module can perform authentication itself, OR # use a Windows Domain Controller. See the radius.conf file # for how to do this. } |
MPPE [RFC3078] 负责将 PMK 发送到 AP。确保设置以下设置
authorize { preprocess mschap suffix eap files } authenticate { # # MSCHAP authentication. Auth-Type MS-CHAP { mschap } # # Allow EAP authentication. eap } |
还要确保 “authorize” 和 “authenticate” 包含然后,更改clients.conf
# Here, we specify which network we're serving client 192.168.0.0/16 { # This is the shared secret between the Authenticator (the # access point) and the Authentication Server (RADIUS). secret = SharedSecret99 shortname = testnet } |
文件以指定它所服务的网络eap.conf也应该非常简单。
将 “default_eap_type” 设置为 “peap”
default_eap_type = peap |
由于 PEAP 使用 TLS,因此 TLS 部分必须包含
tls { # The private key password private_key_password = SecretKeyPass77 # The private key private_key_file = ${raddbdir}/certs/cert-srv.pem # Trusted Root CA list CA_file = ${raddbdir}/certs/demoCA/cacert.pem dh_file = ${raddbdir}/certs/dh random_file = /dev/urandom } |
找到 “peap” 部分,并确保它包含以下内容
peap { # The tunneled EAP session needs a default # EAP type, which is separate from the one for # the non-tunneled EAP module. Inside of the # PEAP tunnel, we recommend using MS-CHAPv2, # as that is the default type supported by # Windows clients. default_eap_type = mschapv2 } |
用户信息存储在纯文本文件users中。可能首选更复杂的解决方案来存储用户信息(SQL、LDAP、PDC 等)。
确保users文件包含以下条目
"testuser" User-Password == "Secret149" |
Supplicant 通常是需要身份验证的笔记本电脑或其他(无线)设备。Xsupplicant 执行 IEEE 802.1X-2001 标准的 “Supplicant” 部分的职责。
安装 Xsupplicant
从 http://www.open1x.org/ 下载最新源代码
# cd /usr/local/src # wget http://belnet.dl.sourceforge.net/sourceforge/open1x/xsupplicant-1.0.tar.gz # tar zxfv xsupplicant-1.0.tar.gz # cd xsupplicant |
配置、make 和 install
# ./configure # make # make install |
如果配置文件未安装(复制)到“etc”文件夹中,请手动执行
# mkdir -p /usr/local/etc/1x # cp etc/tls-example.conf /usr/local/etc/1x |
如果安装失败,请检查README和INSTALL源代码中包含的文件。您也可以查看 官方文档。
配置 Xsupplicant
Supplicant 必须有权访问根证书。
如果 Supplicant 需要针对身份验证服务器进行身份验证(双向身份验证),则 Supplicant 也必须具有证书。
创建一个证书文件夹,并将证书移动到其中
# mkdir -p /usr/local/etc/1x/certs # cp root.pem /usr/local/etc/1x/certs/ # (copy optional client certificate(s) into the same folder) |
打开并编辑配置文件
# startup_command: the command to run when Xsupplicant is first started. # This command can do things such as configure the card to associate with # the network properly. startup_command = <BEGIN_COMMAND>/usr/local/etc/1x/startup.sh<END_COMMAND> |
文件以指定它所服务的网络startup.sh将很快创建。
客户端通过身份验证后,它将传输 DHCP 请求或手动设置 IP 地址。在这里,Supplicant 在startup2.sh:
# first_auth_command: the command to run when Xsupplicant authenticates to # a wireless network for the first time. This will usually be used to # start a DHCP client process. #first_auth_command = <BEGIN_COMMAND>dhclient %i<END_COMMAND> first_auth_command = <BEGIN_COMMAND>/usr/local/etc/1x/startup2.sh<END_COMMAND> |
中手动设置其 IP 地址。由于 “-i” 仅用于调试目的(并且可能会根据开发人员的说法而消失),因此必须设置 “allow_interfaces”
allow_interfaces = eth0 deny_interfaces = eth1 |
接下来,在 “NETWORK SECTION” 下,我们将配置 PEAP
# We'll be using PEAP allow_types = eap_peap # Don't want any eavesdropper to learn the username during the # first phase (which is unencrypted), so 'identity hiding' is # used (using a bogus username). identity = <BEGIN_ID>anonymous<END_ID> eap-peap { # As in tls, define either a root certificate or a directory # containing root certificates. root_cert = /usr/local/etc/1x/certs/root.pem #root_dir = /path/to/root/certificate/dir #crl_dir = /path/to/dir/with/crl chunk_size = 1398 random_file = /dev/urandom #cncheck = myradius.radius.com # Verify that the server certificate # has this value in its CN field. #cnexact = yes # Should it be an exact match? session_resume = yes # Currently 'all' is just mschapv2. # If no allow_types is defined, all is assumed. #allow_types = all # where all = MSCHAPv2, MD5, OTP, GTC, SIM allow_types = eap_mschapv2 # Right now, you can do any of these methods in PEAP: eap-mschapv2 { username = <BEGIN_UNAME>testuser<END_UNAME> password = <BEGIN_PASS>Secret149<END_PASS> } } |
Supplicant 必须首先与接入点关联。脚本startup.sh执行该任务。它也是 Xsupplicant 执行的第一个命令。
![]() | 请注意我们给 iwconfig 的虚假密钥(enc 000000000)!此密钥用于告诉驱动程序以加密模式运行。密钥在成功身份验证后被替换。只有在 AP 中禁用加密(用于测试目的)时,才能将其设置为 enc off。 |
两者startup.sh和startup2.sh必须保存在/usr/local/etc/1x/.
#!/bin/bash echo "Starting startup.sh" # Take down interface (if it's up) /sbin/ifconfig eth0 down # To make sure the routes are flushed sleep 1 # Configuring the interface with a bogus key /sbin/iwconfig eth0 mode managed essid testnet enc 000000000 # Bring the interface up and make sure it listens to multicast packets /sbin/ifconfig eth0 allmulti up echo "Finished startup.sh" |
下。如果 DHCP 服务器存在(通常在许多接入点中都存在),则可以省略下一个文件,该文件用于静态设置 IP 地址。
#!/bin/bash echo "Starting startup2.sh" # Assigning an IP address /sbin/ifconfig eth0 192.168.1.5 netmask 255.255.255.0 echo "Finished startup2.sh" |
在身份验证过程中,Authenticator 仅中继 Supplicant 和身份验证服务器 (RADIUS) 之间的所有消息。EAPOL 用于 Supplicant 和 Authenticator 之间;UDP 用于 Authenticator 和身份验证服务器之间。
许多接入点都支持 802.1X(和 RADIUS)身份验证。必须首先将其配置为使用 802.1X 身份验证。
![]() | 在 AP 上配置和设置 802.1X 可能因供应商而异。 下面列出了使 Cisco AP350 工作的必需设置。也可以配置 TIKP、CCMP 等其他设置。 |
AP 必须将 ESSID 设置为 “testnet”,并且必须激活
图 AP350:Cisco AP-350 的 RADIUS 配置屏幕
802.1X-2001: 确保 802.1X 协议版本设置为 “802.1X-2001”。一些较旧的接入点仅支持 802.1X 标准的草案版本(因此可能无法工作)。
RADIUS 服务器: RADIUS 服务器的名称/IP 地址以及 RADIUS 服务器和接入点之间的共享密钥(在本文档中为“SharedSecret99”)。请参见图 AP350。
EAP 身份验证: RADIUS 服务器应用于 EAP 身份验证。
图 AP350-2:Cisco AP-350 的加密配置屏幕
完全加密 以仅允许加密流量。请注意,802.1X 可以在不使用加密的情况下使用,这对于测试目的来说很好。
开放式身份验证 使 Supplicant 在加密密钥可用之前与接入点关联。关联完成后,Supplicant 可以启动 EAP 身份验证。
需要 EAP 用于 “开放式身份验证”。这将确保只有经过身份验证的用户才能进入网络。
可以将普通的 Linux 节点设置为充当无线接入点和 Authenticator。如何设置和使用 Linux 作为 AP 超出了本文档的范围。Simon Anderson 的 Linux 无线接入点 HOWTO 可能会提供指导。
图 测试平台:无线节点请求身份验证。
我们的测试平台由两个节点和一个接入点 (AP) 组成。一个节点充当 Supplicant (WN),另一个节点充当运行 RADIUS (AS) 的后端身份验证服务器。接入点是 Authenticator。有关说明,请参见图 testbed。
![]() | 至关重要的是,接入点能够到达(ping)身份验证服务器,反之亦然! |
运行一些测试
RADIUS 服务器在调试模式下启动。这将产生大量调试信息。重要的片段如下
radius 服务器现在已准备好处理请求!
上面包含最有趣的输出。如果您收到任何错误消息而不是最后一行,请仔细检查配置(上面)。
现在 Supplicant 已准备好进行身份验证。在调试模式下启动 Xsupplicant。请注意,我们将看到两个启动脚本产生的输出startup.sh和startup2.sh.
# xsupplicant -c /usr/local/etc/1x/1x.conf -i eth0 -d 6 Starting /etc/1x/startup.sh Finished /etc/1x/startup.sh Starting /etc/1x/startup2.sh Finished /etc/1x/startup2.sh |
同时,RADIUS 服务器正在产生大量输出。下面显示了关键片段
Authenticator(接入点)也可能在其日志中显示如下内容
00:02:16 (Info): Station 0002a56fa08a Associated 00:02:17 (Info): Station=0002a56fa08a User="testuser" EAP-Authenticated |
就这样!Supplicant 现在已通过身份验证可以使用接入点!
如 密钥管理 中所述,使用动态 WEP/802.11i 与 802.1X 的一大优势是支持会话密钥。为每个会话生成一个新的加密密钥。
截至撰写本文时,Xsupplicant 仅支持 “动态 WEP”。WPA 和 RSN/WPA2 (802.11i) 的支持正在进行中,据 Xsupplicant 开发人员之一 Chris Hessing 估计,将在今年年底/明年年初 (2004/2005) 得到支持。
并非所有无线驱动器都支持动态 WEP 或 WPA。要使用 RSN (WPA2),甚至可能需要硬件中的新支持。许多较旧的驱动程序假定在任何时候网络上只使用一个 WEP 密钥。每当密钥更改时,卡都会重置,以使新密钥生效。这会触发新的身份验证,并且存在永无止境的循环。
在撰写本文时,基本 Linux 内核中的大多数无线驱动程序都需要修补才能使动态 WEP/WPA 工作。随着时间的推移,它们将被升级以支持这些新功能。但是,许多在内核外部开发的驱动程序都支持动态 WEP;HostAP、madwifi、Orinoco 和 atmel 应该可以正常工作,没有问题。
除了使用 Xsupplicant 之外,还可以使用 wpa_supplicant。wpa_supplicant 支持 WPA 和 RSN (WPA2),以及各种 EAP 身份验证方法。
不要忘记查看 FreeRADIUS(强烈推荐!)和 Xsupplicant 网站的 FAQ 部分!
是的。要使用 EAP-TTLS,只需对本文档中使用的配置进行少量更改即可。要使用 EAP-TLS,也必须使用客户端证书。
是的。Windows XP SP1/Windows 2000 SP3 支持 PEAP MSCHAPv2(本文档中使用)。可以在此处找到 Windows HOWTO:FreeRADIUS/WinXP 身份验证设置
是的。从 Windows XP SP1 或 Windows 2000 SP3 开始,支持 WPA (PEAP/MS-CHAPv2)。其他客户端包括(未经测试)Secure W2(非商业用途免费)和 WIRE1X。Funk Software 也有商业客户端可用。
只有 12 个月之前的 IEEE 标准才对公众开放(通过 “Get IEEE 802 Program”)。因此,新的 802.11i 和 802.1X-2004 标准文档不可用。您必须是 IEEE 参与者才能获得任何草案/正在进行中的论文(实际上这并不难 - 只需加入邮件列表并表示您有兴趣即可)。
FreeRADIUS 服务器项目 http://www.freeradius.org/
Open1x:IEEE 802.1X (Xsupplicant) 的开源实现 http://www.open1x.org/
Open1x 用户指南 http://sourceforge.net/docman/display_doc.php?docid=23371&group_id=60236
基于端口的网络访问控制 (802.1X-2001) http://standards.ieee.org/getieee802/download/802.1X-2001.pdf
RFC2246:TLS 协议版本 1.0 http://www.ietf.org/rfc/rfc2246.txt
RFC2459:Internet X.509 公钥基础设施 - 证书和 CRL 配置文件 http://www.ietf.org/rfc/rfc2459.txt
RFC2548:Microsoft 厂商特定 RADIUS 属性 http://www.ietf.org/rfc/rfc2548.txt
RFC2716:PPP EAP TLS 身份验证协议 http://www.ietf.org/rfc/rfc2716.txt
RFC2865:远程身份验证拨入用户服务 (RADIUS) http://www.ietf.org/rfc/rfc2865.txt
RFC3079:派生密钥以用于 Microsoft 点对点加密 (MPPE) http://www.ietf.org/rfc/rfc3079.txt
RFC3579:RADIUS 对 EAP 的支持 http://www.ietf.org/rfc/rfc3579.txt
RFC3580:IEEE 802.1X RADIUS 使用指南 http://www.ietf.org/rfc/rfc3580.txt
RFC3588:Diameter 基础协议 http://www.ietf.org/rfc/rfc3588.txt
RFC3610:带 CBC-MAC 的计数器 (CCM) http://www.ietf.org/rfc/rfc3610.txt
RFC3748:可扩展身份验证协议 (EAP) http://www.ietf.org/rfc/rfc3748.txt
Linux 无线接入点 HOWTO http://oob.freeshell.org/nzwireless/LWAP-HOWTO.html
SSL 证书 HOWTO http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/
OpenSSL:x509(1) http://www.openssl.org/docs/apps/x509.html
版权所有 (c) 2004 Lars Strand。
根据 GNU 自由文档许可证 1.2 版或自由软件基金会发布的任何后续版本的条款,允许复制、分发和/或修改本文档;不包含不变章节、封面文字和封底文字。 许可证副本包含在题为“GNU 自由文档许可证”的章节中。
感谢 Andreas Hafslund<andreha at unik no>和 Thales Communication 的初步支持。
还要感谢 Artur Hecker<hecker at enst fr>、Chris Hessing<chris hessing at utah edu>、Jouni Malinen<jkmaline at cc hut fi>和 Terry Simons<galimore at mac com>提供的宝贵反馈!
感谢 Rick Moen<rick at linuxmafia com>进行了语言审查!
版权所有 (C) 2000,2001,2002 自由软件基金会,Inc. 美国马萨诸塞州波士顿市寺庙广场 59 号 330 室,邮编 02111-1307 允许任何人复制和分发此许可证文档的完整副本,但不允许更改它。
本许可证的目的是使手册、教科书或其他功能性和有用的文档在自由意义上“自由”:确保每个人都拥有有效自由来复制和再分发它,无论是否进行修改,无论是商业用途还是非商业用途。 其次,本许可证为作者和出版商保留了一种获得作品署名权的方式,同时不被视为对他人所做的修改负责。
本许可证是一种“反版权”,这意味着文档的衍生作品本身必须在相同意义上是自由的。 它补充了 GNU 通用公共许可证,后者是为自由软件设计的反版权许可证。
我们设计本许可证是为了将其用于自由软件的手册,因为自由软件需要自由文档:自由程序应附带提供与软件相同自由度的手册。 但本许可证不限于软件手册; 它可用于任何文本作品,无论主题事项或是否作为印刷书籍出版。 我们主要推荐本许可证用于以指导或参考为目的的作品。
本许可证适用于任何手册或其他作品,以任何媒介形式,其中包含版权持有人放置的声明,声明可以根据本许可证的条款分发。 此类声明授予全球范围内的、免版税的许可证,期限不限,以根据本文所述的条件使用该作品。 下文的“文档”是指任何此类手册或作品。 任何公众成员都是被许可人,并被称为“您”。 如果您以根据版权法需要许可的方式复制、修改或分发作品,则您接受本许可证。
文档的“修改版本”是指包含文档或其一部分的任何作品,无论是逐字复制,还是经过修改和/或翻译成另一种语言。
“次要章节”是指文档的命名附录或前言章节,专门处理文档的出版商或作者与文档的总体主题(或相关事项)的关系,并且不包含任何可能直接属于该总体主题的内容。 (因此,如果文档部分是数学教科书,则次要章节不得解释任何数学知识。) 这种关系可能是与主题或相关事项的历史联系,或与有关它们的法律、商业、哲学、伦理或政治立场有关。
“不变章节”是某些次要章节,其标题在声明文档根据本许可证发布的声明中被指定为不变章节的标题。 如果章节不符合上述次要章节的定义,则不允许将其指定为不变章节。 文档可能包含零个不变章节。 如果文档未识别任何不变章节,则不存在不变章节。
“封面文字”是在声明文档根据本许可证发布的声明中列出的某些简短的文本段落,作为封面文字或封底文字。 封面文字最多可以有 5 个字,封底文字最多可以有 25 个字。
文档的“透明”副本是指机器可读副本,以通用公众可用的规范格式表示,适用于使用通用文本编辑器(对于像素组成的图像)或通用绘图程序(对于绘图)直接修订文档,并且适用于输入到文本格式化程序或自动翻译成各种适用于输入到文本格式化程序的格式。 以其他透明文件格式制作的副本,其标记或缺少标记旨在阻止或劝阻读者后续修改,则不是透明的。 如果图像格式用于大量文本,则不是透明的。 不是“透明”的副本称为“不透明”。
透明副本的合适格式示例包括不带标记的纯 ASCII、Texinfo 输入格式、LaTeX 输入格式、使用公开可用的 DTD 的 SGML 或 XML,以及符合标准的简单 HTML、PostScript 或 PDF,专为人工修改而设计。 透明图像格式的示例包括 PNG、XCF 和 JPG。 不透明格式包括只能由专有文字处理器读取和编辑的专有格式,DTD 和/或处理工具通常不可用的 SGML 或 XML,以及某些文字处理器仅出于输出目的而生成的机器生成的 HTML、PostScript 或 PDF。
“标题页”对于印刷书籍而言,是指标题页本身,以及为清晰地容纳本许可证要求出现在标题页中的材料所需的后续页面。 对于没有标题页格式的作品,“标题页”是指作品标题最突出显示的外观附近的文本,位于正文文本的开头之前。
“题为 XYZ”的章节是指文档的命名子单元,其标题要么精确地是 XYZ,要么包含括号中的 XYZ,后跟用另一种语言翻译 XYZ 的文本。 (此处 XYZ 代表下面提到的特定章节名称,例如“致谢”、“题献”、“认可”或“历史”。) 当您修改文档时,“保留”此类章节的“标题”是指它仍然是根据本定义“题为 XYZ”的章节。
文档可能在声明本许可证适用于文档的声明旁边包含保修免责声明。 这些保修免责声明被认为通过引用包含在本许可证中,但仅限于免除保修:这些保修免责声明可能具有的任何其他含义均无效,并且对本许可证的含义没有影响。
您可以以任何媒介复制和分发文档,无论是商业用途还是非商业用途,前提是本许可证、版权声明以及声明本许可证适用于文档的许可证声明在所有副本中都得到复制,并且您不得对本许可证的条款添加任何其他条件。 您不得使用技术措施来阻止或控制您制作或分发的副本的阅读或进一步复制。 但是,您可以接受报酬以换取副本。 如果您分发足够多的副本,您还必须遵守第 3 节中的条件。
您也可以在上述相同条件下借出副本,并且您可以公开展示副本。
如果您出版印刷版副本(或通常带有印刷封面的媒体中的副本)的文档,数量超过 100 份,并且文档的许可证声明要求封面文字,则您必须将副本装在封面上,封面上清晰且清晰地印有所有这些封面文字:封面文字在封面上,封底文字在封底上。 两个封面还必须清晰且清晰地标明您是这些副本的出版商。 封面必须以同等突出且可见的方式呈现完整标题的所有字词。 您还可以在封面上添加其他材料。 对封面的更改仅限于保留文档标题并满足这些条件的副本,在其他方面可以视为逐字复制。
如果任一封面的所需文字太多而无法清晰地容纳,您应将列出的第一个文字(尽可能多地容纳)放在实际封面上,并将其余文字继续放在相邻页面上。
如果您出版或分发超过 100 份文档的不透明副本,则您必须包含机器可读的透明副本以及每个不透明副本,或者在每个不透明副本中或与其一起声明计算机网络位置,公众可以使用公共标准网络协议从该位置下载文档的完整透明副本,且不包含添加的材料。 如果您使用后一种选择,则当您开始大量分发不透明副本时,您必须采取合理谨慎的步骤,以确保透明副本在该声明的位置保持可访问,直到至少在您最后一次向公众分发该版本的任何不透明副本(直接或通过您的代理或零售商)后一年为止。
建议但不要求您在重新分发大量副本之前与文档的作者联系,让他们有机会为您提供文档的更新版本。
您可以根据上述第 2 节和第 3 节的条件复制和分发文档的修改版本,前提是您根据本许可证精确地发布修改版本,修改版本扮演文档的角色,从而许可向拥有其副本的任何人分发和修改修改版本。 此外,您必须在修改版本中执行以下操作
在标题页上(以及封面上,如果有的话)使用与文档标题不同的标题,以及与先前版本的标题不同的标题(如果存在任何先前版本,应在文档的历史记录章节中列出)。 如果先前版本的原始出版商给予许可,您可以使用与先前版本相同的标题。
在标题页上,列出修改版本中修改的作者的一个或多个人员或实体,以及文档的至少五位主要作者(如果主要作者少于五位,则列出所有主要作者),除非他们免除您的此项要求。
在标题页上,声明修改版本的出版商的姓名,作为出版商。
保留文档的所有版权声明。
在其他版权声明旁边添加适用于您的修改的适当版权声明。
在版权声明之后立即包含许可证声明,允许公众根据本许可证的条款使用修改版本,如以下附录中所示。
在该许可证声明中保留文档许可证声明中给出的不变章节和所需封面文字的完整列表。
包含本许可证的未更改副本。
保留题为“历史记录”的章节,保留其标题,并在其中添加一项,至少说明标题页上给出的修改版本的标题、年份、新作者和出版商。 如果文档中没有题为“历史记录”的章节,则创建一个章节,说明标题页上给出的文档的标题、年份、作者和出版商,然后添加一项,描述如前一句所述的修改版本。
保留文档中给出的任何网络位置,以便公众访问文档的透明副本,以及文档中给出的文档所基于的先前版本的网络位置。 这些可以放在“历史记录”章节中。 您可以省略在文档本身出版前至少四年出版的作品的网络位置,或者如果它所指版本的原始出版商给予许可。
对于任何题为“致谢”或“题献”的章节,保留该章节的标题,并在该章节中保留其中给出的每个贡献者致谢和/或题献的所有实质内容和语气。
保留文档的所有不变章节,其文本和标题均未更改。 章节编号或等效内容不被视为章节标题的一部分。
删除任何题为“认可”的章节。 修改版本中不得包含此类章节。
不要重命名任何现有章节使其题为“认可”或在标题上与任何不变章节冲突。
保留任何保修免责声明。
如果修改版本包含符合次要章节条件的新前言章节或附录,并且不包含从文档复制的材料,您可以选择将其中一些或所有章节指定为不变。 为此,请将它们的标题添加到修改版本的许可证声明中的不变章节列表中。 这些标题必须与任何其他章节标题不同。
您可以添加一个题为“认可”的章节,前提是它仅包含各个方面对您的修改版本的认可——例如,同行评审声明或文本已被某个组织批准为标准的权威定义。
您可以添加最多五个字的段落作为封面文字,以及最多 25 个字的段落作为封底文字,添加到修改版本的封面文字列表的末尾。 任何一个实体(或通过其安排)最多可以添加一个封面文字段落和一个封底文字段落。 如果文档已经包含同一封面的封面文字,该封面文字是您先前添加的或由您代表的同一实体安排添加的,则您不得添加另一个; 但您可以替换旧的封面文字,前提是获得添加旧封面文字的先前出版商的明确许可。
文档的作者和出版商未通过本许可证授予使用其姓名进行宣传或声明或暗示认可任何修改版本的许可。
您可以将文档与根据本许可证发布的其他文档合并,根据第 4 节中为修改版本定义的条款,前提是您在合并版本中包含所有原始文档的所有不变章节,未修改,并将它们全部列为组合作品的许可证声明中的不变章节,并且您保留它们的所有保修免责声明。
组合作品只需要包含本许可证的一个副本,并且多个相同的不变章节可以用单个副本替换。 如果存在多个名称相同但内容不同的不变章节,请通过在其末尾添加括号中的该章节的原始作者或出版商的姓名(如果已知),或者添加唯一编号,使每个此类章节的标题唯一。 对组合作品的许可证声明中的不变章节列表中的章节标题进行相同的调整。
在组合中,您必须合并各个原始文档中题为“历史记录”的任何章节,形成一个题为“历史记录”的章节; 同样合并任何题为“致谢”的章节,以及任何题为“题献”的章节。 您必须删除所有题为“认可”的章节。
您可以制作一个集合,其中包含文档和根据本许可证发布的其他文档,并将各个文档中本许可证的单独副本替换为集合中包含的单个副本,前提是您在所有其他方面都遵循本许可证关于逐字复制每个文档的规则。
您可以从这样的集合中提取单个文档,并根据本许可证单独分发它,前提是您将本许可证的副本插入到提取的文档中,并在所有其他方面都遵循本许可证关于该文档的逐字复制。
文档或其衍生作品与其他单独且独立的文档或作品在存储或分发介质的卷中或卷上的汇编称为“聚合”,如果汇编产生的版权不用于限制汇编用户的合法权利,超出各个作品允许的范围。 当文档包含在聚合中时,本许可证不适用于聚合中并非文档衍生作品的其他作品。
如果第 3 节的封面文字要求适用于文档的这些副本,那么如果文档小于整个聚合的一半,则文档的封面文字可以放在括起聚合中文档的封面上,或者如果文档是电子形式,则放在封面的电子等效物上。 否则,它们必须出现在括起整个聚合的印刷封面上。
翻译被视为一种修改,因此您可以根据第 4 节的条款分发文档的翻译。 将不变章节替换为翻译需要其版权持有人的特殊许可,但您可以除了这些不变章节的原始版本外,还可以包含一些或全部不变章节的翻译。 您可以包含本许可证的翻译,以及文档中的所有许可证声明和任何保修免责声明,前提是您还包含本许可证的原始英文版本以及这些声明和免责声明的原始版本。 如果本许可证的翻译版本与原始版本或声明或免责声明之间存在分歧,则以原始版本为准。
如果文档中的章节题为“致谢”、“题献”或“历史记录”,则(第 4 节)保留其标题(第 1 节)的要求通常需要更改实际标题。
除非本许可证明确规定,否则您不得复制、修改、再许可或分发文档。 任何其他复制、修改、再许可或分发文档的尝试均无效,并将自动终止您在本许可证下的权利。 但是,根据本许可证从您那里收到副本或权利的当事方,只要这些当事方保持完全合规,其许可证就不会终止。
自由软件基金会可能会不时发布 GNU 自由文档许可证的新修订版本。 此类新版本在精神上将与当前版本相似,但在细节上可能有所不同,以解决新问题或疑虑。 请参阅 https://gnu.ac.cn/copyleft/。
许可证的每个版本都给出了一个区分版本号。 如果文档指定本许可证的特定编号版本“或任何后续版本”适用于它,您可以选择遵循该指定版本或自由软件基金会已发布(未作为草案)的任何后续版本的条款和条件。 如果文档未指定本许可证的版本号,您可以选择自由软件基金会曾经发布(未作为草案)的任何版本。
要在您编写的文档中使用本许可证,请在文档中包含本许可证的副本,并将以下版权和许可证声明放在标题页之后
版权所有 (c) YEAR 您的姓名。 根据 GNU 自由文档许可证 1.2 版或自由软件基金会发布的任何后续版本的条款,允许复制、分发和/或修改本文档;不包含不变章节、封面文字和封底文字。 许可证副本包含在题为“GNU 自由文档许可证”的章节中。
如果您有不变章节、封面文字和封底文字,请将“不包含...文字。” 行替换为此
不变章节为 列出其标题,封面文字为 列出,封底文字为 列出。
如果您有不带封面文字的不变章节,或者这三者的其他某种组合,请合并这两种备选方案以适应具体情况。
如果您的文档包含程序代码的非平凡示例,我们建议根据您选择的自由软件许可证(例如 GNU 通用公共许可证)并行发布这些示例,以允许在自由软件中使用它们。