Network Working Group                                   M. Parthasarathy
Request for Comments: 4016                                         Nokia
Category: Informational                                       March 2005
        
Network Working Group                                   M. Parthasarathy
Request for Comments: 4016                                         Nokia
Category: Informational                                       March 2005
        

Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements

承载身份验证和网络访问(PANA)威胁分析和安全要求的协议

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 (2005).

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

Abstract

摘要

This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol.

本文档讨论用于进行网络访问身份验证的协议面临的威胁。这些威胁产生的安全要求将作为协议的额外输入,用于承载网络访问认证(PANA)工作组设计基于IP的网络访问认证协议。

Table of Contents

目录

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  Terminology and Definitions. . . . . . . . . . . . . . . . . .  2
   4.  Usage Scenarios. . . . . . . . . . . . . . . . . . . . . . . .  3
   5.  Trust Relationships. . . . . . . . . . . . . . . . . . . . . .  4
   6.  Threat Scenarios . . . . . . . . . . . . . . . . . . . . . . .  5
       6.1.  PAA Discovery. . . . . . . . . . . . . . . . . . . . . .  6
       6.2.  Authentication . . . . . . . . . . . . . . . . . . . . .  6
       6.3.  PaC Leaving the Network. . . . . . . . . . . . . . . . .  9
       6.4.  Service Theft. . . . . . . . . . . . . . . . . . . . . . 10
       6.5.  PAA-EP Communication . . . . . . . . . . . . . . . . . . 11
       6.6.  Miscellaneous Attacks. . . . . . . . . . . . . . . . . . 12
   7.  Summary of Requirements. . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 13
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 14
   10. Informative References . . . . . . . . . . . . . . . . . . . . 14
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15
        
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  Terminology and Definitions. . . . . . . . . . . . . . . . . .  2
   4.  Usage Scenarios. . . . . . . . . . . . . . . . . . . . . . . .  3
   5.  Trust Relationships. . . . . . . . . . . . . . . . . . . . . .  4
   6.  Threat Scenarios . . . . . . . . . . . . . . . . . . . . . . .  5
       6.1.  PAA Discovery. . . . . . . . . . . . . . . . . . . . . .  6
       6.2.  Authentication . . . . . . . . . . . . . . . . . . . . .  6
       6.3.  PaC Leaving the Network. . . . . . . . . . . . . . . . .  9
       6.4.  Service Theft. . . . . . . . . . . . . . . . . . . . . . 10
       6.5.  PAA-EP Communication . . . . . . . . . . . . . . . . . . 11
       6.6.  Miscellaneous Attacks. . . . . . . . . . . . . . . . . . 12
   7.  Summary of Requirements. . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 13
   9.  Normative References . . . . . . . . . . . . . . . . . . . . . 14
   10. Informative References . . . . . . . . . . . . . . . . . . . . 14
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15
        
1. Introduction
1. 介绍

The Protocol for Carrying Authentication for Network Access (PANA) Working Group is developing methods for authenticating clients to the access network using IP based protocols. This document discusses the threats to such IP based protocols.

网络接入认证协议(PANA)工作组正在开发使用基于IP的协议对接入网络的客户端进行认证的方法。本文档讨论此类基于IP的协议面临的威胁。

A client wishing to get access to the network must carry on multiple steps. First, it needs to discover the IP address of the PANA authentication agent (PAA) and then execute an authentication protocol to authenticate itself to the network. Once the client is authenticated, there might be other messages exchanged during the lifetime of the network access. This document discusses the threats in these steps without discussing any solutions. The requirements arising out of these threats will be used as input to the PANA Working Group. The use of word co-located in this document means that the referred entities are present on the same node.

希望访问网络的客户端必须执行多个步骤。首先,它需要发现PANA身份验证代理(PAA)的IP地址,然后执行身份验证协议以向网络进行身份验证。一旦客户端通过身份验证,在网络访问的生命周期内可能会交换其他消息。本文档讨论了这些步骤中的威胁,但未讨论任何解决方案。这些威胁产生的要求将作为PANA工作组的投入。在本文档中使用“共定位”一词意味着引用的实体存在于同一节点上。

2. Keywords
2. 关键词

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。

3. Terminology and Definitions
3. 术语和定义

Client Access Device

客户端访问设备

A network element (e.g., notebook computer, PDA) that requires access to a provider's network.

需要访问提供商网络的网络元件(如笔记本电脑、PDA)。

Network Access Server (NAS)

网络访问服务器(NAS)

Network device that provides access to the network.

提供网络访问的网络设备。

PANA Client (PaC)

泛亚客户(PaC)

An entity in the edge subnet that seeks to obtain network access from a PANA authentication agent within a network. A PANA client is associated with a device and a set of credentials to prove its identity within the scope of PANA.

边缘子网中的一种实体,用于从网络中的PANA身份验证代理获取网络访问权限。PANA客户端与设备和一组凭证相关联,以证明其在PANA范围内的身份。

PANA Authentication Agent (PAA)

PANA身份验证代理(PAA)

An entity whose responsibility is to authenticate the PANA client and to grant network access service to the client's device.

一种实体,其职责是对PANA客户端进行身份验证,并向客户端设备授予网络访问服务。

Authentication Server (AS)

身份验证服务器(AS)

An entity that authenticates the PANA client. It may be co-located with the PANA authentication agent or part of the back-end infrastructure.

对PANA客户端进行身份验证的实体。它可能与PANA身份验证代理或后端基础设施的一部分位于同一位置。

Device Identifier (DI)

设备标识符(DI)

The identifier used by the network to control and police the network access of a client. Depending on the access technology, the identifier might contain the IP address, link-layer address, switch port number, etc., of a device. The PANA authentication agent keeps a table for binding device identifiers to the PANA clients. At most one PANA client should be associated with a DI on a PANA authentication agent.

网络用于控制和监控客户端网络访问的标识符。根据访问技术,标识符可能包含设备的IP地址、链路层地址、交换机端口号等。PANA身份验证代理保留一个表,用于将设备标识符绑定到PANA客户端。最多一个PANA客户端应与PANA身份验证代理上的DI相关联。

Enforcement Point (EP)

执行点(EP)

A node capable of filtering packets sent by the PANA client by using the DI information authorized by PANA authentication agent.

能够使用PANA认证代理授权的DI信息过滤PANA客户端发送的数据包的节点。

Compound methods

复合方法

Authentication protocol in which methods are used in a sequence one after another or in which methods are tunneled inside another independently established tunnel between the client and server [TUN-EAP].

一种认证协议,其中方法按顺序依次使用,或者方法在客户机和服务器之间另一个独立建立的隧道中进行隧道传输[TUN-EAP]。

4. Usage Scenarios
4. 使用场景

PANA is intended to be used in an environment where there is no a priori trust relationship or security association between the PaC and other nodes, such as the PAA and EP. In these environments, one may observe the following:

PANA旨在用于PaC和其他节点(如PAA和EP)之间不存在先验信任关系或安全关联的环境中。在这些环境中,可以观察到以下情况:

o The link between PaC and PAA may be a shared medium (e.g., Ethernet) or may not be a shared medium (e.g., DSL network).

o PaC和PAA之间的链路可以是共享介质(例如以太网),也可以不是共享介质(例如DSL网络)。

o All the PaCs may be authenticated to the access network at layer 2 (e.g., 3GPP2 CDMA network) and share a security association with a layer 2 authentication agent (e.g., BTS). The PaCs still don't trust each other; any PaC can pretend to be a PAA, spoof IP addresses, and launch various other attacks.

o 所有pac可在第2层(例如3GPP2 CDMA网络)处被认证到接入网络,并与第2层认证代理(例如BTS)共享安全关联。PAC仍然彼此不信任;任何PaC都可以伪装成PAA,伪造IP地址,并发起各种其他攻击。

The scenarios mentioned above affect the threat model of PANA. This document discusses the various threats in the context of the above network access scenarios for a better understanding of the threats. In the following discussion, any reference to a link that is not

上述场景会影响PANA的威胁模型。为了更好地理解这些威胁,本文档将在上述网络访问场景中讨论各种威胁。在下面的讨论中,对链接的任何引用

shared (or non-shared) is assumed to be physically secure. If such an assumption cannot be made about the link, then the case becomes the same as that for a link being shared by more than one node.

共享(或非共享)被认为是物理安全的。如果不能对链路做出这样的假设,则情况与由多个节点共享的链路的情况相同。

5. Trust Relationships
5. 信任关系

PANA authentication involves a client (PaC), a PANA agent (PAA), an Authentication server (AS), and an Enforcement point (EP). The AS here refers to the AAA server that resides in the home realm of the PaC.

PANA身份验证涉及客户端(PaC)、PANA代理(PAA)、身份验证服务器(AS)和实施点(EP)。此处的AS指的是驻留在PaC主域中的AAA服务器。

The entities that have a priori trust relationships before PANA begins are as follows:

在PANA开始之前具有先验信任关系的实体如下:

1) PAA and AS: The PaC belonging to the same administrative domain that the AS does often has to use resources provided by a PAA that belongs to another administrative domain. A PAA authenticates the PaC before providing local network access. The credentials provided by the PaC for authentication may or may not be understood by the PAA. If the PAA does not understand the credentials, it needs to communicate with the AS in a different domain to verify the credentials. The threats in the communication path between the PAA and AS are already covered in [RAD-EAP]. To counter these threats, the communication between the PAA and AS is secured by using a static or dynamic security association.

1) PAA和AS:与AS属于同一管理域的PaC通常必须使用由属于另一管理域的PAA提供的资源。PAA在提供本地网络访问之前对PaC进行身份验证。PaC提供的认证凭证可能被PAA理解,也可能不被PAA理解。如果PAA不理解凭据,则需要与其他域中的AS通信以验证凭据。PAA和AS之间通信路径中的威胁已在[RAD-EAP]中介绍。为了应对这些威胁,通过使用静态或动态安全关联来保护PAA和AS之间的通信。

2) PAA and EP: The PAA and EP belong to the same administrative domain. Hence, the network operator can set up a security association to protect the traffic exchanged between them. This document discusses the threats in this path.

2) PAA和EP:PAA和EP属于同一管理域。因此,网络运营商可以建立一个安全关联来保护它们之间交换的流量。本文档讨论此路径中的威胁。

3) PaC and AS: The PaC and AS belong to the same administrative domain and share a trust relationship. When the PaC uses a different domain than its home for network access, it provides its credentials to the PAA in the visited network for authentication. The information provided by the PaC traverses the PaC-PAA and PAA-AS paths. The threats in the PAA-AS path are already discussed in [RAD-EAP]. This document discusses the threats in the PaC-PAA path.

3) PaC和AS:PaC和AS属于同一管理域并共享信任关系。当PaC使用与其家庭不同的域进行网络访问时,它会将其凭据提供给访问网络中的PAA进行身份验证。PaC提供的信息遍历PaC PAA和PAA-AS路径。PAA-AS路径中的威胁已在[RAD-EAP]中讨论。本文档讨论PaC PAA路径中的威胁。

It is possible that some of the entities such as the PAA, AS, and EP are co-located. In those cases, it can be safely assumed that there are no significant external threats in their communication.

一些实体(如PAA、as和EP)可能位于同一地点。在这些情况下,可以安全地假设他们的通信中没有重大的外部威胁。

The entities that do not have any trust relationship before PANA begins are as follows:

在PANA开始之前没有任何信任关系的实体如下:

1) PaC and PAA: The PaC and PAA normally belong to two different administrative domains. They do not necessarily share a trust relationship initially. They establish a security association in the process of authentication. All messages exchanged between the PaC and PAA are subject to various threats, which are discussed in this document.

1) PaC和PAA:PaC和PAA通常属于两个不同的管理域。他们最初并不一定共享信任关系。它们在身份验证过程中建立安全关联。PaC和PAA之间交换的所有消息都会受到各种威胁,本文对此进行了讨论。

2) PaC and EP: The EP belongs to the same administrative domain as the PAA. Hence, the PaC and EP do not necessarily share a trust relationship initially. When the PaC is successfully authenticated, it may result in key establishment between the PaC and PAA, which can be further used to secure the link between the PaC and EP. For example, the EAP keying framework, [EAP-KEY], defines a three party EAP exchange in which the clients derive the transient sessions keys to secure the link between the peer and NAS in their final step. Similarly, PANA will provide the ability to establish keys between the PaC and EP that can be used to secure the link further. This is discussed further in Section 6.4 below.

2) PaC和EP:EP与PAA属于同一行政领域。因此,PaC和EP最初不一定共享信任关系。当PaC成功通过身份验证时,可能会导致PaC和PAA之间建立密钥,这可进一步用于保护PaC和EP之间的链路。例如,EAP密钥框架[EAP-KEY]定义了一个三方EAP交换,在该交换中,客户端派生临时会话密钥,以在其最后一步保护对等方和NAS之间的链路。同样,PANA将提供在PaC和EP之间建立密钥的能力,该密钥可用于进一步保护链路。下文第6.4节将对此进行进一步讨论。

6. Threat Scenarios
6. 威胁情景

First, the PaC needs to discover the PAA. This involves either sending solicitations or waiting for advertisements. Once it has discovered the PAA, the two will enter authentication exchange. Once the access is granted, the PaC will most likely exchange data with other nodes in the Internet. These steps are vulnerable to man-in-the-middle (MITM), denial of service (DoS), and service theft attacks, which are discussed below.

首先,PaC需要发现PAA。这包括发送邀约或等待广告。一旦发现了PAA,这两个将进入身份验证交换。一旦授权访问,PaC很可能会与Internet上的其他节点交换数据。这些步骤容易受到中间人(MITM)、拒绝服务(DoS)和服务盗窃攻击的攻击,这些攻击将在下文讨论。

The threats are grouped by the various stages the client goes through to gain access to the network. Section 6.1 discusses the threats related to PAA discovery. Section 6.2 discusses the threats related to authentication itself. Section 6.3 discusses the threats involved when leaving the network. Section 6.4 discusses service theft. Section 6.5 discusses the threats in the PAA-EP path. Section 6.6 discusses the miscellaneous threats.

威胁按客户端访问网络所经历的不同阶段进行分组。第6.1节讨论了与PAA发现相关的威胁。第6.2节讨论了与身份验证本身相关的威胁。第6.3节讨论了离开网络时所涉及的威胁。第6.4节讨论服务盗窃。第6.5节讨论了PAA-EP路径中的威胁。第6.6节讨论了各种威胁。

Some of the threats discussed in the following sections may be specific to shared links. The threat may be absent on non-shared links. Hence, it is only required to prevent the threat on shared links. Instead of specifying a separate set of requirements for shared links and non-shared links, this document specifies one set of requirements with the following wording: "PANA MUST be able to prevent threat X". This means that the PANA protocol should be capable of preventing threat X. The feature that prevents threat X may or may not be used depending on the deployment.

以下部分讨论的一些威胁可能特定于共享链接。非共享链接上可能不存在威胁。因此,只需要防止共享链接上的威胁。本文件没有为共享链接和非共享链接规定单独的一组要求,而是规定了一组要求,并使用以下措辞:“PANA必须能够防止X威胁”。这意味着PANA协议应该能够防止威胁X。根据部署情况,可以使用或不使用防止威胁X的功能。

6.1. PAA Discovery
6.1. PAA发现

The PAA is discovered by sending solicitations or receiving advertisements. The following are possible threats.

PAA是通过发送邀约或接收广告发现的。以下是可能的威胁。

T6.1.1: A malicious node can pretend to be a PAA by sending a spoofed advertisement.

T6.1.1:恶意节点可通过发送虚假广告假装为PAA。

In existing dial-up networks, the clients authenticate to the network but generally do not verify the authenticity of the messages coming from Network Access Server (NAS). This mostly works because the link between the device and the NAS is not shared with other nodes (assuming that nobody tampers with the physical link), and clients trust the NAS and the phone network to provide the service. Spoofing attacks are not present in this environment, as the PaC may assume that the other end of the link is the PAA.

在现有拨号网络中,客户端通过网络身份验证,但通常不验证来自网络访问服务器(NAS)的消息的真实性。这主要是因为设备和NAS之间的链路不与其他节点共享(假设没有人篡改物理链路),并且客户端信任NAS和电话网络来提供服务。此环境中不存在欺骗攻击,因为PaC可能假定链路的另一端是PAA。

In environments where the link is shared, this threat is present, as any node can pretend to be a PAA. Even if the nodes are authenticated at layer 2, the threat remains present. It is difficult to protect the discovery process, as there is no a priori trust relationship between the PAA and PaC. In deployments where EP can police the packets that are sent among the PaCs, it is possible to filter out the unauthorized PANA packets (e.g., PAA advertisements sent by PaC) to prevent this threat.

在共享链接的环境中,这种威胁是存在的,因为任何节点都可以假装是PAA。即使节点在第2层进行了身份验证,威胁仍然存在。很难保护发现过程,因为PAA和PaC之间没有先验的信任关系。在EP可以监控PaC之间发送的数据包的部署中,可以过滤掉未经授权的PANA数据包(例如,PaC发送的PAA广告),以防止这种威胁。

The advertisement may be used to include information (such as supported authentication methods) other than the discovery of the PAA itself. This can lead to a bidding down attack, as a malicious node can send a spoofed advertisement with capabilities that indicate authentication methods less secure than those that the real PAA supports, thereby fooling the PaC into negotiating an authentication method less secure than would otherwise be available.

广告可用于包括除PAA本身的发现之外的信息(例如支持的认证方法)。这可能导致竞价拒绝攻击,因为恶意节点可以发送欺骗广告,其功能表明身份验证方法不如真正的PAA支持的方法安全,从而欺骗PaC协商一种不安全的身份验证方法。

Requirement 1

要求1

PANA MUST not assume that the discovery process is protected.

PANA不得假设发现过程受到保护。

6.2. Authentication
6.2. 认证

This section discusses the threats specific to the authentication protocol. Section 6.2.1 discusses the possible threat associated with success/failure indications that are transmitted to PaC at the end of the authentication. Section 6.2.2 discusses the man-in-the-middle attack when compound methods are used. Section 6.2.3 discusses the replay attack, and Section 6.2.4 discusses the device identifier attack.

本节讨论特定于身份验证协议的威胁。第6.2.1节讨论了与认证结束时传输给PaC的成功/失败指示相关的可能威胁。第6.2.2节讨论了使用复合方法时的中间人攻击。第6.2.3节讨论了重播攻击,第6.2.4节讨论了设备标识符攻击。

6.2.1. Success or Failure Indications
6.2.1. 成功或失败迹象

Some authentication protocols (e.g., EAP) have a special message to indicate success or failure. An attacker can send a false authentication success or failure message to the PaC. By sending a false failure message, the attacker can prevent the client from accessing the network. By sending a false success message, the attacker can prematurely end the authentication exchange, effectively denying service for the PaC.

某些身份验证协议(如EAP)有一条特殊的消息来指示成功或失败。攻击者可以向PaC发送错误的身份验证成功或失败消息。通过发送错误的失败消息,攻击者可以阻止客户端访问网络。通过发送错误的成功消息,攻击者可以提前结束身份验证交换,从而有效地拒绝PaC的服务。

If the link is not shared, then this threat is absent, as ingress filtering can prevent the attacker from impersonating the PAA.

如果链接未共享,则不存在此威胁,因为入口过滤可防止攻击者模拟PAA。

If the link is shared, it is easy to spoof these packets. If layer 2 provides per-packet encryption with pair-wise keys, it might make it hard for the attacker to guess the success or failure packet that the client would accept. Even if the node is already authenticated at layer 2, it can still pretend to be a PAA and spoof the success or failure.

如果链接是共享的,很容易欺骗这些数据包。如果第2层使用成对密钥提供每个数据包的加密,则攻击者可能难以猜测客户端将接受的成功或失败数据包。即使节点已经在第2层进行了身份验证,它仍然可以假装是PAA并欺骗成功或失败。

This attack is possible if the success or failure indication is not protected by using a security association between the PaC and the PAA. In order to avoid this attack, the PaC and PAA should mutually authenticate each other. In this process, they should be able to establish keys to protect the success or failure indications. It may not always be possible to protect the indication, as the keys may not be established prior to transmitting the success or failure packet. If the client is re-authenticating to the network, it can use the previously established security association to protect the success or failure indications. Similarly, all PANA messages exchanged during the authentication prior to key establishment may not be protected.

如果成功或失败指示未使用PaC和PAA之间的安全关联进行保护,则可能发生此攻击。为了避免这种攻击,PaC和PAA应该相互认证。在此过程中,他们应该能够建立密钥来保护成功或失败指示。可能并不总是能够保护指示,因为在传输成功或失败分组之前可能没有建立密钥。如果客户端正在对网络进行重新身份验证,它可以使用先前建立的安全关联来保护成功或失败指示。类似地,在密钥建立之前的身份验证期间交换的所有PANA消息可能不受保护。

Requirement 2

要求2

PANA MUST be able to mutually authenticate the PaC and PAA. PANA MUST be able to establish keys between the PaC and PAA to protect the PANA messages.

PANA必须能够相互验证PaC和PAA。PANA必须能够在PaC和PAA之间建立密钥,以保护PANA消息。

6.2.2. MITM Attack
6.2.2. MITM攻击

A malicious node can claim to be the PAA to the real PaC and claim to be the PaC to the real PAA. This is a man-in-the-middle (MITM) attack, whereby the PaC is fooled to think that it is communicating with the real PAA and the PAA is fooled to think that it is communicating with the real PaC.

恶意节点可以声称是真实PaC的PAA,也可以声称是真实PAA的PaC。这是一个中间人(MITM)攻击,其中PaC被愚弄以为它在与真正的PAA通信,而PAA被愚弄以为它在与真正的PaC通信。

If the link is not shared, this threat is absent, as ingress filtering can prevent the attacker from acting as a man-in-the-middle.

如果链接未共享,则不存在此威胁,因为入口过滤可以防止攻击者充当中间人。

If the link is shared, this threat is present. Even if the layer 2 provides per-packet protection, the attacker can act as a man-in-the-middle and launch this attack. An instance of MITM attack, in which compound authentication methods are used is described in [TUN-EAP]. In these attacks, the server first authenticates to the client. As the client has not proven its identity yet, the server acts as the man-in-the-middle, tunneling the identity of the legitimate client to gain access to the network. The attack is possible because there is no verification that the same entities participated among the compound methods. It is not possible to do such verification if compound methods are used without being able to create a cryptographic binding among them. This implies that PANA will be vulnerable to such attacks if compound methods are used without being able to cryptographically bind them. Note that the attack does not exist if the keys derived during the tunnel establishment are not used to authenticate the client (e.g., tunnel keys are used for just protecting the identity of the client).

如果链接是共享的,则存在此威胁。即使第2层提供每个数据包的保护,攻击者也可以充当中间人,发起此攻击。[TUN-EAP]中描述了使用复合身份验证方法的MITM攻击实例。在这些攻击中,服务器首先向客户端进行身份验证。由于客户端尚未证明其身份,服务器充当中间人,通过隧道传输合法客户端的身份以访问网络。攻击是可能的,因为无法验证复合方法中是否有相同的实体参与。如果使用复合方法而不能在它们之间创建加密绑定,则不可能进行这种验证。这意味着,如果使用复合方法而不能以加密方式绑定它们,PANA将容易受到此类攻击。请注意,如果在隧道建立期间派生的密钥不用于对客户端进行身份验证(例如,隧道密钥仅用于保护客户端的身份),则攻击不存在。

Requirement 3

要求3

When compound authentication methods are used in PANA, the methods MUST be cryptographically bound.

在PANA中使用复合身份验证方法时,这些方法必须以加密方式绑定。

6.2.3. Replay Attack
6.2.3. 重放攻击

A malicious node can replay the messages that caused authentication failure or success at a later time to create false failures or success. The attacker can also potentially replay other messages of the PANA protocol to deny service to the PaC.

恶意节点可以在以后重播导致身份验证失败或成功的消息,以创建错误的失败或成功。攻击者还可能重播PANA协议的其他消息,以拒绝向PaC提供服务。

If the link is not shared, this threat is absent, as ingress filtering can prevent the attacker from impersonating the PAA to replay the packets.

如果链接未共享,则不存在此威胁,因为入口过滤可防止攻击者模拟PAA重播数据包。

If the link is shared, this threat is present. If the packets are encrypted at layer 2 by using pair-wise keys, it will make it hard for the attacker to learn the unencrypted (i.e., original) packet that needs to be replayed. Even if layer 2 provides replay protection, the attacker can still replay the PANA messages (layer 3) for denying service to the client.

如果链接是共享的,则存在此威胁。如果在第2层使用成对密钥对数据包进行加密,则攻击者将难以识别需要重放的未加密(即原始)数据包。即使第2层提供重播保护,攻击者仍可以重播PANA消息(第3层),以拒绝向客户端提供服务。

Requirement 4

要求4

PANA MUST be able to protect itself against replay attacks.

PANA必须能够保护自己免受重播攻击。

6.2.4. Device Identifier Attack
6.2.4. 设备标识符攻击

When the client is successfully authenticated, the PAA sends access control information to the EP for granting access to the network. The access control information typically contains the device identifier of the PaC, which is either obtained from the IP headers and MAC headers of the packets exchanged during the authentication process or carried explicitly in the PANA protocol field. The attacker can gain unauthorized access into the network by taking the following steps.

当客户端成功通过身份验证时,PAA向EP发送访问控制信息,以授予对网络的访问权。访问控制信息通常包含PaC的设备标识符,该标识符或者从认证过程中交换的分组的IP报头和MAC报头中获得,或者显式地携带在PANA协议字段中。攻击者可以通过以下步骤获得对网络的未经授权访问。

o An attacker pretends to be a PAA and sends advertisements. The PaC is fooled and starts exchanging packets with the attacker.

o 攻击者假装是PAA并发送广告。PaC被愚弄并开始与攻击者交换数据包。

o The attacker modifies the IP source address on the packet, adjusts the UDP/TCP checksum, and forwards the packet to the real PAA. It also does the same on return packets.

o 攻击者修改数据包上的IP源地址,调整UDP/TCP校验和,并将数据包转发给真正的PAA。它在返回数据包时也会执行相同的操作。

o When the real PaC is successfully authenticated, the attacker gains access to the network, as the packets contained the IP address (and potentially the MAC address also) of the attacker.

o 当真正的PaC成功通过身份验证时,攻击者可以访问网络,因为数据包包含攻击者的IP地址(可能还有MAC地址)。

If the link is not shared, this threat is absent, as the attacker cannot impersonate the PAA and intercept the packets from the PaC.

如果链接未共享,则不存在此威胁,因为攻击者无法模拟PAA并拦截来自PaC的数据包。

If the link is shared, this threat is present. If the layer 2 provides per-packet protection, it is not possible to change the MAC address, and hence this threat may be absent in such cases if EP filters on both the IP and MAC address.

如果链接是共享的,则存在此威胁。如果第2层提供每包保护,则不可能更改MAC地址,因此,如果EP同时在IP和MAC地址上进行过滤,则在这种情况下可能不存在这种威胁。

Requirement 5

要求5

PANA MUST be able to protect the device identifier against spoofing when it is exchanged between the PaC and PAA.

在PaC和PAA之间交换设备标识符时,PANA必须能够保护设备标识符不受欺骗。

6.3. PaC Leaving the Network
6.3. PaC离开网络

When the PaC leaves the network, it can inform the PAA before disconnecting from the network so that the resources used by PaC can be accounted properly. The PAA may also choose to revoke the access anytime it deems necessary. The following are possible threats:

当PaC离开网络时,它可以在断开与网络的连接之前通知PAA,以便正确核算PaC使用的资源。PAA也可以在其认为必要的任何时候撤销访问权。以下是可能的威胁:

T6.3.1: A malicious node can pretend to be a PAA and revoke the access to PaC.

T6.3.1:恶意节点可以假装是PAA并撤销对PaC的访问。

T6.3.2: A malicious node can pretend to be a real PaC and transmit a disconnect message.

T6.3.2:恶意节点可以假装是真实的PaC并传输断开连接消息。

T6.3.3: The PaC can leave the network without notifying the PAA or EP (e.g., the Ethernet cable is unplugged, system crash). An attacker can pretend to be the PaC and start using the network.

T6.3.3:PaC可以在不通知PAA或EP的情况下离开网络(例如,以太网电缆被拔下,系统崩溃)。攻击者可以假装是PaC并开始使用网络。

If the link is not shared, threats T6.3.1 and T6.3.2 are absent. Threat T6.3.3 may still be present. If there is no layer 2 indication, or if the layer 2 indication cannot be relied upon, then threat T6.3.3 is still present on non-shared links.

如果链路未共享,则不存在威胁T6.3.1和T6.3.2。威胁T6.3.3可能仍然存在。如果没有第2层指示,或者无法依赖第2层指示,则威胁T6.3.3仍存在于非共享链路上。

If the link is shared, all of the above threats are present, as any node on the link can spoof the disconnect message. Even if layer 2 has per-packet authentication, the attacker can pretend to be a PaC (e.g., by spoofing the IP address) and disconnect from the network. Similarly, any node can pretend to be a PAA and revoke the access to the PaC. Therefore, T6.3.1 and T6.3.2 are possible even on links where layer 2 is secured. Threat T6.3.3 can be prevented if layer 2 provides per-packet authentication. The attacker cannot subsume the PaC that left the network without knowing the keys that protect the packet at layer 2.

如果链接是共享的,则会出现上述所有威胁,因为链接上的任何节点都可能伪造断开连接消息。即使第2层具有每包身份验证,攻击者也可以假装是PaC(例如,通过欺骗IP地址)并断开与网络的连接。类似地,任何节点都可以假装是PAA并撤销对PaC的访问。因此,T6.3.1和T6.3.2即使在第2层固定的链路上也是可能的。如果第2层提供每包身份验证,则可以防止威胁T6.3.3。攻击者在不知道保护第2层数据包的密钥的情况下,无法包含离开网络的PaC。

Requirement 6

要求6

PANA MUST be able to protect disconnect and revocation messages. PANA MUST NOT depend on the PaC sending a disconnect message.

PANA必须能够保护断开连接和撤销消息。PANA不得依赖PaC发送断开连接消息。

6.4. Service Theft
6.4. 服务盗窃

An attacker can gain unauthorized access into the network by stealing the service from another client. Once the real PaC is successfully authenticated, the EP will have filters in place to prevent unauthorized access into the network. The filters will be based on something that will be carried on every packet. For example, the filter could be based on the IP and MAC addresses, where the packets will be dropped unless the packets coming with certain IP addresses also match the MAC addresses. The following are possible threats:

攻击者可以通过从另一个客户端窃取服务来获得对网络的未经授权访问。一旦真正的PaC成功通过身份验证,EP将安装过滤器,以防止未经授权访问网络。过滤器将基于每个数据包上携带的内容。例如,过滤器可以基于IP和MAC地址,其中分组将被丢弃,除非具有特定IP地址的分组也与MAC地址匹配。以下是可能的威胁:

T6.4.1: An attacker can spoof both the IP and MAC addresses of an authorized client to gain unauthorized access. The attacker can launch this attack easily by just sniffing the wire for IP and MAC addresses. This lets the attacker use the network without any authorization, getting a free service.

T6.4.1:攻击者可以欺骗授权客户端的IP和MAC地址,以获得未经授权的访问。攻击者只需嗅探线路上的IP和MAC地址,即可轻松发起此攻击。这使得攻击者可以在没有任何授权的情况下使用网络,从而获得免费服务。

T6.4.2: The PaC can leave the network without notifying the PAA or EP (e.g., the Ethernet cable is unplugged, system crash). An attacker can pretend to be the PaC and start using the network.

T6.4.2:PaC可以在不通知PAA或EP的情况下离开网络(例如,以太网电缆被拔下,系统崩溃)。攻击者可以假装是PaC并开始使用网络。

Service theft allows the possibility of exploiting the weakness in other authentication protocols that use IP address for authentication. It also allows the interception of traffic destined for other nodes by spoofing the IP address.

服务盗窃允许利用使用IP地址进行身份验证的其他身份验证协议中的弱点。它还允许通过欺骗IP地址拦截发送给其他节点的流量。

If the link is not shared, T6.4.1 is absent, as there is only one client on the link, and ingress filtering can prevent the use of the authorized IP and MAC addresses by the attacker on another link. Threat T6.4.2 exists, as the attacker can use the IP or MAC address of the real PaC to gain access to the network.

如果链路未共享,则T6.4.1将不存在,因为链路上只有一个客户端,并且入口过滤可防止攻击者在另一个链路上使用授权的IP和MAC地址。威胁T6.4.2存在,因为攻击者可以使用真实PaC的IP或MAC地址访问网络。

If the link is shared, both the threats are present. If layer 2 provides per-packet protection using pair-wise keys, both the threats can be prevented.

如果链接是共享的,则两种威胁都存在。如果第2层使用成对密钥提供每个数据包的保护,则可以防止这两种威胁。

Requirement 7

要求7

PANA MUST securely bind the authenticated session to the device identifier of the client, to prevent service theft. PANA MUST be able to bootstrap a shared secret between the PaC and PAA that can be further used to set up a security association between the PaC and EP to provide cryptographic protection against service theft.

PANA必须将经过身份验证的会话安全地绑定到客户端的设备标识符,以防止服务被盗。PANA必须能够引导PaC和PAA之间的共享秘密,该秘密可进一步用于在PaC和EP之间建立安全关联,以提供针对服务盗窃的加密保护。

6.5. PAA-EP Communication
6.5. PAA-EP通信

After a successful authentication, the PAA needs to communicate the access control information of the PaC to the EP so that the PaC will be allowed to access the network. The information communicated would contain at least the device identifier of the PaC. If strong security is needed, the PAA will communicate a shared secret known only to the PaC and PAA, for setting up a security association between the PaC and EP. The following are possible threats:

认证成功后,PAA需要将PaC的访问控制信息传送给EP,以便允许PaC访问网络。所传送的信息将至少包含PaC的设备标识符。如果需要强大的安全性,PAA将传递一个只有PaC和PAA知道的共享秘密,以便在PaC和EP之间建立安全关联。以下是可能的威胁:

T6.5.1: An attacker can eavesdrop to learn the information communicated between the PAA and EP. The attacker can further use this information to spoof the real PaC and also to set up security association for gaining access to the network. This threat is absent if the attacker cannot eavesdrop on the link; e.g., the PAA and EP communicate on a link separate from that of visiting PaCs.

T6.5.1:攻击者可以窃听以了解PAA和EP之间通信的信息。攻击者可以进一步利用此信息欺骗真实的PaC,并建立安全关联以访问网络。如果攻击者无法窃听链接,则不存在此威胁;e、 例如,PAA和EP通过独立于访问PaCs的链路进行通信。

T6.5.2: An attacker can pretend to be a PAA and send false information to an EP to gain access to the network. In the case of stronger security, the attacker has to send its own device identifier and also a shared secret, so that the EP will let the attacker access the network.

T6.5.2:攻击者可以假装是PAA,并向EP发送虚假信息以访问网络。在安全性更强的情况下,攻击者必须发送自己的设备标识符和共享密钥,以便EP允许攻击者访问网络。

If the communication between the PAA and EP is protected, these threats are absent.

如果PAA和EP之间的通信受到保护,则不存在这些威胁。

Requirement 8

要求8

The communication between the PAA and EP MUST be protected against eavesdropping and spoofing attacks.

必须保护PAA和EP之间的通信免受窃听和欺骗攻击。

6.6. Miscellaneous Attacks
6.6. 恶意攻击

T6.6.1: There are various forms of DoS attacks that can be launched on the PAA or AS. A few are mentioned below. As it is hard to defend against some of the DoS attacks, the protocol should be designed carefully to mitigate or prevent such attacks.

T6.6.1:有多种形式的DoS攻击可在PAA或AS上发起。下面提到了一些。由于很难抵御某些DoS攻击,因此应仔细设计协议以减轻或防止此类攻击。

o An attacker can bombard the PAA with lots of authentication requests. If the PAA and AS are not co-located, the PAA may have to allocate resources to store some state about the PaC locally before it receives the response from the back-end AS. This can deplete memory resources on the PAA.

o 攻击者可以用大量身份验证请求轰炸PAA。如果PAA和AS不在同一位置,PAA可能必须在接收到来自后端AS的响应之前,分配资源以在本地存储PaC的某些状态。这会耗尽PAA上的内存资源。

o With minimal effort, an attacker can force the PAA or AS to make computationally intensive operations with minimal effort, that can deplete the CPU resources of the PAA or AS.

o 攻击者只需付出最小的努力,就可以迫使PAA或AS以最小的努力进行计算密集型操作,从而耗尽PAA或AS的CPU资源。

T6.6.2: PaC acquires an IP address by using stateful or stateless mechanisms before PANA authentication begins [PANAREQ]. When the IP addresses are assigned before the client authentication, it opens up the possibility of DoS attacks in which unauthenticated malicious nodes can deplete the IP address space by acquiring multiple IP addresses or deny allocation to others by responding to every duplicate address detection (DAD) query.

T6.6.2:PaC在PANA认证开始[PANAREQ]之前,通过使用有状态或无状态机制获取IP地址。如果在客户端身份验证之前分配IP地址,则可能会出现DoS攻击,未经身份验证的恶意节点可通过获取多个IP地址耗尽IP地址空间,或通过响应每个重复地址检测(DAD)查询拒绝分配给其他节点。

Depleting a /64 IPv6 link-local address space or a /8 RFC1918 private address space requires a brute-force attack. Such an attack is part of a DoS class that can equally target the link capacity or the CPU cycles on the target system by bombarding arbitrary packets. Therefore, solely handling the IP address depletion attack is not going to improve the security, as a more general solution is needed to tackle the whole class of brute-force attacks.

耗尽/64 IPv6链路本地地址空间或/8 RFC1918专用地址空间需要暴力攻击。此类攻击是DoS类的一部分,它可以通过轰炸任意数据包来同等地针对目标系统上的链路容量或CPU周期。因此,单独处理IP地址耗尽攻击不会提高安全性,因为需要更通用的解决方案来处理整个类别的暴力攻击。

The DAD attack can be prevented by deploying secure address resolution that does not depend on the client authentication,

通过部署不依赖于客户端身份验证的安全地址解析,可以防止DAD攻击,

such as [SEND]. The attack may also be prevented if the EP is placed between the PaCs to monitor the ND/ARP activity and to detect DAD attacks (excessive NA/ARP replies). If none of these solutions are applicable to a deployment, the PaCs can send arbitrary packets to each other without going through the EP, which enables a class of attacks that are based on interfering with the PANA messaging (See T6.1.1). Since there will always be a threat in this class (e.g., insecure discovery), it is not going to improve the overall security by addressing DAD.

例如[发送]。如果EP放置在PAC之间以监控ND/ARP活动并检测DAD攻击(过多的NA/ARP回复),则也可以防止攻击。如果这些解决方案都不适用于部署,PaCs可以在不经过EP的情况下向彼此发送任意数据包,这会导致一类基于干扰PANA消息的攻击(参见T6.1.1)。由于此类中始终存在威胁(例如,不安全的发现),因此它不会通过解决DAD来提高总体安全性。

7. Summary of Requirements
7. 所需资源摘要

1. PANA MUST not assume that the discovery process is protected.

1. PANA不得假设发现过程受到保护。

2. PANA MUST be able to mutually authenticate the PaC and PAA. PANA MUST be able to establish keys between the PaC and PAA to protect the PANA messages.

2. PANA必须能够相互验证PaC和PAA。PANA必须能够在PaC和PAA之间建立密钥,以保护PANA消息。

3. When compound authentication methods are used in PANA, the methods MUST be cryptographically bound.

3. 在PANA中使用复合身份验证方法时,这些方法必须以加密方式绑定。

4. PANA MUST be able to protect itself against replay attacks.

4. PANA必须能够保护自己免受重播攻击。

5. PANA MUST be able to protect the device identifier against spoofing when it is exchanged between the PaC and PAA.

5. 在PaC和PAA之间交换设备标识符时,PANA必须能够保护设备标识符不受欺骗。

6. PANA MUST be able to protect disconnect and revocation messages. PANA MUST NOT depend on whether the PaC sends a disconnect message.

6. PANA必须能够保护断开连接和撤销消息。PANA不得依赖于PaC是否发送断开连接消息。

7. PANA MUST securely bind the authenticated session to the device identifier of the client, to prevent service theft. PANA MUST be able to bootstrap a shared secret between the PaC and PAA that can be further used to set up a security association between the PaC and EP to provide cryptographic protection against service theft.

7. PANA必须将经过身份验证的会话安全地绑定到客户端的设备标识符,以防止服务被盗。PANA必须能够引导PaC和PAA之间的共享秘密,该秘密可进一步用于在PaC和EP之间建立安全关联,以提供针对服务盗窃的加密保护。

8. The communication between the PAA and EP MUST be protected against eavesdropping and spoofing attacks.

8. 必须保护PAA和EP之间的通信免受窃听和欺骗攻击。

8. Security Considerations
8. 安全考虑

This document discusses various threats with IP based network access authentication protocol. Though this document discusses the threats for shared and unshared links separately, it may be difficult to make such a distinction in practice (e.g., a dial-up link may be a point-to-point IP tunnel). Hence, the link should be assumed to be a shared link for most of the threats in this document.

本文档讨论基于IP的网络访问身份验证协议的各种威胁。尽管本文档分别讨论了共享和非共享链路的威胁,但在实践中可能很难进行区分(例如,拨号链路可能是点对点IP隧道)。因此,对于本文档中的大多数威胁,应假定该链接为共享链接。

9. Normative References
9. 规范性引用文件

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[关键词]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

10. Informative References
10. 资料性引用

[PANAREQ] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, "Protocol for Carrying Authentication for Network Access (PANA) Requirements and Terminology", Work in Progress, August 2004.

[PANAREQ]Yegin,A.,Ed.,Ohba,Y.,Penno,R.,Tsirtsis,G.,和C.Wang,“承载网络访问认证(PANA)要求和术语的协议”,正在进行的工作,2004年8月。

[EAP-KEY] Aboba, B., et al., "EAP keying framework", Work in Progress.

[EAP-KEY]Aboba,B.等人,“EAP键控框架”,正在进行的工作。

[RAD-EAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.

[RAD-EAP]Aboba,B.和P.Calhoun,“RADIUS(远程认证拨入用户服务)对可扩展认证协议(EAP)的支持”,RFC 3579,2003年9月。

[TUN-EAP] Puthenkulam, J., et al., "The compound authentication binding problem", Work in Progress.

[TUN-EAP]Puthenkulam,J.等,“复合认证绑定问题”,正在进行中。

[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

[发送]Arkko,J.,Ed.,Kempf,J.,Zill,B.,和P.Nikander,“安全邻居发现(发送)”,RFC 39712005年3月。

11. Acknowledgements
11. 致谢

The author would like to thank the following people (in no specific order) for providing valuable comments: Alper Yegin, Basavaraj Patil, Pekka Nikander, Bernard Aboba, Francis Dupont, Michael Thomas, Yoshihiro Ohba, Gabriel Montenegro, Tschofenig Hannes, Bill Sommerfeld, N. Asokan, Pete McCan, Derek Atkins, and Thomas Narten.

作者要感谢以下人士(无具体顺序)提供了宝贵的意见:阿尔珀·叶金、巴萨瓦拉吉·帕蒂尔、佩卡·尼坎德、伯纳德·阿博巴、弗朗西斯·杜邦、迈克尔·托马斯、大叶吉弘、加布里埃尔·黑山、茨霍芬尼·汉内斯、比尔·索末菲、阿育王、皮特·麦肯、德里克·阿特金斯和托马斯·纳滕。

Author's Address

作者地址

Mohan Parthasarathy Nokia 313 Fairchild Drive Mountain View, CA-94303

Mohan Parthasarathy诺基亚313飞兆半导体山景大道,CA-94303

   EMail: mohanp@sbcglobal.net
        
   EMail: mohanp@sbcglobal.net
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2005).

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

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

本文件及其包含的信息是按“原样”提供的,贡献者、他/她所代表或赞助的组织(如有)、互联网协会和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.

Acknowledgement

确认

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

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