Network Working Group J. Loughney
Request for Comments: 3702 Nokia
Category: Informational G. Camarillo
Ericsson
February 2004
Network Working Group J. Loughney
Request for Comments: 3702 Nokia
Category: Informational G. Camarillo
Ericsson
February 2004
Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP)
会话启动协议（SIP）的身份验证、授权和记帐要求
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 (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
As Session Initiation Protocol (SIP) services are deployed on the Internet, there is a need for authentication, authorization, and accounting of SIP sessions. This document sets out the basic requirements for this work.
由于会话发起协议（SIP）服务部署在Internet上，因此需要对SIP会话进行身份验证、授权和记帐。本文件规定了这项工作的基本要求。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 4
1.3. Requirements Language. . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Common Requirements. . . . . . . . . . . . . . . . . . . 5
2.1.1. Communication within the Same Domain . . . . . . 5
2.1.2. Communication between Different Domains. . . . . 5
2.1.3. Discovery. . . . . . . . . . . . . . . . . . . . 5
2.1.4. Ability to Integrate Different Networks,
Services and Users . . . . . . . . . . . . . . . 5
2.1.5. Updating SIP Server Entries. . . . . . . . . . . 5
2.1.6. SIP Session Changes. . . . . . . . . . . . . . . 5
2.1.7. Reliable Transfer of Protocol Messages . . . . . 5
2.1.8. Call Setup Times . . . . . . . . . . . . . . . . 6
2.1.9. Security . . . . . . . . . . . . . . . . . . . . 6
2.2. Authentication Requirements. . . . . . . . . . . . . . . 6
2.2.1. Authentication Based on SIP Requests . . . . . . 6
2.2.2. Flexible Authentication of SIP Requests. . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 4
1.3. Requirements Language. . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Common Requirements. . . . . . . . . . . . . . . . . . . 5
2.1.1. Communication within the Same Domain . . . . . . 5
2.1.2. Communication between Different Domains. . . . . 5
2.1.3. Discovery. . . . . . . . . . . . . . . . . . . . 5
2.1.4. Ability to Integrate Different Networks,
Services and Users . . . . . . . . . . . . . . . 5
2.1.5. Updating SIP Server Entries. . . . . . . . . . . 5
2.1.6. SIP Session Changes. . . . . . . . . . . . . . . 5
2.1.7. Reliable Transfer of Protocol Messages . . . . . 5
2.1.8. Call Setup Times . . . . . . . . . . . . . . . . 6
2.1.9. Security . . . . . . . . . . . . . . . . . . . . 6
2.2. Authentication Requirements. . . . . . . . . . . . . . . 6
2.2.1. Authentication Based on SIP Requests . . . . . . 6
2.2.2. Flexible Authentication of SIP Requests. . . . . 6
2.3. Authorization Requirements . . . . . . . . . . . . . . . 6
2.3.1. Ability to Authorize SIP Requests. . . . . . . . 7
2.3.2. Information Transfer . . . . . . . . . . . . . . 7
2.3.3. User De-authorization. . . . . . . . . . . . . . 7
2.3.4. User Re-authorization. . . . . . . . . . . . . . 7
2.3.5. Support for Credit Control . . . . . . . . . . . 7
2.4. Accounting Requirements. . . . . . . . . . . . . . . . . 8
2.4.1. Separation of Accounting Information . . . . . . 8
2.4.2. Accounting Information Related to Session
Progression. . . . . . . . . . . . . . . . . . . 8
2.4.3. Accounting Information Not Related to Session
Progression. . . . . . . . . . . . . . . . . . . 9
2.4.4. Support for One-Time and Session-based
Accounting Records . . . . . . . . . . . . . . . 9
2.4.5. Support for Accounting on Different Media
Components . . . . . . . . . . . . . . . . . . . 9
2.4.6. Configuration of Accounting Generation
Parameters. . . . . . . . . . . . . . . . . . . 9
2.4.7. Support for Arbitrary Correlations . . . . . . . 9
3. Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. WLAN Roaming Using Third Party Service Providers . . . . 11
3.2. Conditional Authorization. . . . . . . . . . . . . . . . 12
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 13
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
2.3. Authorization Requirements . . . . . . . . . . . . . . . 6
2.3.1. Ability to Authorize SIP Requests. . . . . . . . 7
2.3.2. Information Transfer . . . . . . . . . . . . . . 7
2.3.3. User De-authorization. . . . . . . . . . . . . . 7
2.3.4. User Re-authorization. . . . . . . . . . . . . . 7
2.3.5. Support for Credit Control . . . . . . . . . . . 7
2.4. Accounting Requirements. . . . . . . . . . . . . . . . . 8
2.4.1. Separation of Accounting Information . . . . . . 8
2.4.2. Accounting Information Related to Session
Progression. . . . . . . . . . . . . . . . . . . 8
2.4.3. Accounting Information Not Related to Session
Progression. . . . . . . . . . . . . . . . . . . 9
2.4.4. Support for One-Time and Session-based
Accounting Records . . . . . . . . . . . . . . . 9
2.4.5. Support for Accounting on Different Media
Components . . . . . . . . . . . . . . . . . . . 9
2.4.6. Configuration of Accounting Generation
Parameters. . . . . . . . . . . . . . . . . . . 9
2.4.7. Support for Arbitrary Correlations . . . . . . . 9
3. Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. WLAN Roaming Using Third Party Service Providers . . . . 11
3.2. Conditional Authorization. . . . . . . . . . . . . . . . 12
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 13
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
The AAA working group is chartered to work on authentication, authorization, and accounting solutions for the Internet. This work consists of a base protocol, applications, end-to-end security application, and a general architecture for providing these services [3]. The AAA working group has specified applicability of AAA-based solutions for a number of protocols (e.g., AAA requirements for Mobile IP [4]).
AAA工作组被特许从事互联网认证、授权和计费解决方案的工作。这项工作包括基本协议、应用程序、端到端安全应用程序以及提供这些服务的通用体系结构[3]。AAA工作组规定了基于AAA的解决方案对许多协议的适用性（例如，移动IP的AAA要求[4]）。
SIP is a signalling protocol for creating, modifying, and terminating different types of sessions, such as Internet phone calls, multimedia distribution, and multimedia conferences [1]. SIP sessions have needs for session authentication, authorization, and accounting (AAA).
SIP是一种信令协议，用于创建、修改和终止不同类型的会话，如Internet电话呼叫、多媒体分发和多媒体会议[1]。SIP会话需要会话身份验证、授权和记帐（AAA）。
In order to authenticate and authorize users, it is typically more convenient for SIP entities to communicate with an AAA sever than to attempt to store user credentials and profiles locally. SIP entities use the SIP-AAA interface to access the AAA server.
为了对用户进行身份验证和授权，SIP实体与AAA服务器通信通常比在本地存储用户凭据和配置文件更方便。SIP实体使用SIP-AAA接口访问AAA服务器。
This document provides requirements for the interface between SIP entities and AAA servers. While accounting requirements are discussed, this document does not cover SIP charging or billing mechanisms.
本文档提供了SIP实体和AAA服务器之间的接口要求。虽然讨论了会计要求，但本文档不包括SIP收费或计费机制。
One possible use of this document would be to create an AAA application for SIP. Any protocol meeting the requirements outlined by this document could be used. Possible candidates, among others, are Diameter [3] and XML-based protocols following the web-services model.
本文档的一个可能用途是为SIP创建AAA应用程序。可使用符合本文件所述要求的任何协议。可能的候选协议包括Diameter[3]和遵循web服务模型的基于XML的协议。
The main purpose of this document is to provide input to designers working on AAA applications using new protocols, such as Diameter and XML-based protocols. Nevertheless, a few limited RADIUS [5] extensions may meet some of the requirements in this document (for instance, some of the authentication requirements). We expect that while RADIUS with these limited extensions will meet particular functional requirements, it will not meet other important requirements. The following are some requirements that are not expected to be met by RADIUS:
本文档的主要目的是为使用新协议（如Diameter和基于XML的协议）处理AAA应用程序的设计人员提供输入。然而，一些有限半径[5]扩展可能满足本文件中的一些要求（例如，一些认证要求）。我们预计，尽管带有这些有限扩展的RADIUS将满足特定的功能需求，但它不会满足其他重要需求。以下是RADIUS预计无法满足的一些要求：
1. Section 2.1.3: RADIUS does not support a discovery feature.
1. 第2.1.3节：RADIUS不支持查找功能。
2. Section 2.1.7: RADIUS does not support reliable message delivery.
2. 第2.1.7节：RADIUS不支持可靠的消息传递。
The following list contains the requirements that can be met by RADIUS or RADIUS extensions.
以下列表包含半径或半径扩展可以满足的要求。
1. Section 2.1.2: Communication between domains does not scale well in RADIUS. As a result, inter-domain communications are typically handled using a proxy architecture [6].
1. 第2.1.2节：域之间的通信在RADIUS中无法很好地扩展。因此，域间通信通常使用代理体系结构进行处理[6]。
2. Section 2.1.5: RADIUS clients would need to support Dynamic Authorization [7].
2. 第2.1.5节：RADIUS客户端需要支持动态授权[7]。
3. Section 2.1.9: RADIUS clients would need to rely on a lower-layer security protocol, such as IPSec, to perform mutual authentication.
3. 第2.1.9节：RADIUS客户端需要依赖较低层的安全协议（如IPSec）来执行相互身份验证。
4. Section 2.3.3: RADIUS clients would need to support Dynamic Authorization [7].
4. 第2.3.3节：RADIUS客户端需要支持动态授权[7]。
5. Section 2.3.4: RADIUS clients would need to support Dynamic Authorization [7].
5. 第2.3.4节：RADIUS客户端需要支持动态授权[7]。
AAA: Authentication, Authorization, and Accounting
AAA：身份验证、授权和记帐
Accounting: The collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. Accounting management requires that resource consumption be measured, rated, assigned, and communicated between appropriate parties [8].
会计：收集资源消耗数据，用于容量和趋势分析、成本分配、审计和计费。会计管理要求在相关方之间对资源消耗进行计量、评级、分配和沟通[8]。
Accounting with credit control: The application checks the end user's account for coverage for the requested service event charge prior to execution of that service event.
信用控制会计：在执行该服务事件之前，应用程序检查最终用户的帐户是否包含请求的服务事件费用。
Home AAA Server: Server where user with which the user maintains an account relationship.
家庭AAA服务器：与用户保持帐户关系的用户所在的服务器。
SIP: Session Initiation Protocol
会话启动协议
SIP proxies: SIP proxies are nodes which forward SIP requests and responses, as well as make policy decisions.
SIP代理：SIP代理是转发SIP请求和响应以及做出策略决策的节点。
UAC: User Agent Client
用户代理客户端
UAS: User Agent Server
用户代理服务器
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2].
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的说明进行解释。
In this section, we list the requirements. Protocol solutions are not required to satisfy requirements for services that they do not support. For example, a solution that provides authentication services but not accounting services does not need to fulfill the accounting requirements. It is expected that solutions will fulfill the general requirements, plus the requirements for the specific services they are providing.
在本节中，我们列出了需求。协议解决方案不需要满足它们不支持的服务的需求。例如，提供身份验证服务但不提供记帐服务的解决方案不需要满足记帐要求。预计解决方案将满足一般要求，以及它们所提供的特定服务的要求。
Section 2.1 lists general requirements, Section 2.2 lists requirements related to authentication, Section 2.3 lists requirements related to authorization, and Section 2.4 lists requirements related to accounting.
第2.1节列出了一般要求，第2.2节列出了与认证相关的要求，第2.3节列出了与授权相关的要求，第2.4节列出了与会计相关的要求。
This section outlines general requirements on the SIP-AAA interface.
本节概述了SIP-AAA接口的一般要求。
The SIP-AAA interface MUST support communications between a SIP entity and an AAA server that belong to the same domain.
SIP-AAA接口必须支持SIP实体和属于同一域的AAA服务器之间的通信。
The SIP-AAA interface MUST support communications between a SIP entity in one domain and an AAA server in another domain. This MAY involve a proxy or a redirect server architecture between both entities.
SIP-AAA接口必须支持一个域中的SIP实体和另一个域中的AAA服务器之间的通信。这可能涉及两个实体之间的代理或重定向服务器体系结构。
With the information contained in the SIP messages, the SIP-AAA interface SHOULD be able to deduce the particular AAA server that has to be queried.
通过SIP消息中包含的信息，SIP-AAA接口应该能够推断出必须查询的特定AAA服务器。
The basic AAA architecture MUST be access independent. Service providers have to be able to provide AAA services for SIP, irrespective of access method or technology.
基本AAA体系结构必须是独立于访问的。服务提供商必须能够为SIP提供AAA服务，无论访问方法或技术如何。
When required, the SIP-AAA interface MUST allow the AAA server to update the information that a SIP entity has about a user.
需要时，SIP-AAA接口必须允许AAA服务器更新SIP实体拥有的关于用户的信息。
The SIP-AAA interface MUST allow a SIP entity to inform the AAA server about changes in the SIP session that may affect the authorization, authentication, or accounting for that SIP session.
SIP-AAA接口必须允许SIP实体通知AAA服务器SIP会话中可能影响该SIP会话的授权、身份验证或记帐的更改。
The SIP-AAA interface SHOULD provide a reliable transfer of AAA protocol messages between the SIP entity and the AAA server.
SIP-AAA接口应在SIP实体和AAA服务器之间提供AAA协议消息的可靠传输。
AAA SHOULD NOT unduly burden call setup times where appropriate. It may be reasonable to support some delay during registration, but delay during on-going sessions (especially real-time) is problematic.
在适当的情况下，AAA不应过度增加呼叫设置时间。在注册期间支持一些延迟可能是合理的，但是在正在进行的会话（特别是实时会话）期间的延迟是有问题的。
The SIP-AAA interface is a potential target of an attack. An eavesdropper may attempt to obtain confidential data by sniffing messages. Additionally, an active attacker may attempt to modify, insert, or replay messages between the SIP entity and the AAA server. Attackers may also attempt to impersonate legitimate SIP entities or AAA servers.
SIP-AAA接口是潜在的攻击目标。窃听者可能试图通过嗅探消息来获取机密数据。此外，主动攻击者可能会试图在SIP实体和AAA服务器之间修改、插入或重播消息。攻击者还可能试图模拟合法的SIP实体或AAA服务器。
To address these threats, the SIP-AAA interface MUST support confidentiality, data origin authentication, integrity, and replay protection. In addition to this, bi-directional authentication between the SIP entity and the AAA server MUST be supported as well.
为了应对这些威胁，SIP-AAA接口必须支持机密性、数据源身份验证、完整性和重播保护。除此之外，还必须支持SIP实体和AAA服务器之间的双向身份验证。
This section outlines requirements on the SIP-AAA interface related to authentication.
本节概述了与身份验证相关的SIP-AAA接口的要求。
The home AAA server MUST be able to authenticate a user based on any SIP request, except CANCELs and ACKs for non-2xx final responses.
家庭AAA服务器必须能够基于任何SIP请求对用户进行身份验证，非2xx最终响应的取消和确认除外。
CANCELs and ACKs for non-2xx final responses are hop-by-hop requests that can be generated by proxies that do not have the user's credentials.
非2xx最终响应的取消和确认是逐跳请求，可由不具有用户凭据的代理生成。
The SIP-AAA interface MUST be flexible enough to accommodate a variety of authentication mechanisms used to authenticate SIP requests. In particular, the SIP-AAA interface MUST be able to accommodate all the authentication mechanisms mandated by the SIP specifications (e.g., Digest authentication).
SIP-AAA接口必须足够灵活，以适应用于验证SIP请求的各种身份验证机制。特别是，SIP-AAA接口必须能够容纳SIP规范规定的所有认证机制（例如，摘要认证）。
This section outlines requirements on the SIP-AAA interface related to authorization.
本节概述了与授权相关的SIP-AAA接口要求。
The SIP-AAA interface MUST allow AAA servers to authorize any SIP request, except CANCELs and ACKs for non-2xx final responses.
SIP-AAA接口必须允许AAA服务器授权任何SIP请求，非2xx最终响应的取消和确认除外。
CANCELs and ACKs for non-2xx final responses are hop-by-hop requests that can be generated by proxies. SIP servers receiving a CANCEL or a ACK for a non-2xx final response do not challenge them, as they would do with an end-to-end request. Instead, they check at the transport or network layer that the entity sending the CANCEL or the ACK is the same as the one that generated the request being canceled or acked.
非2xx最终响应的取消和确认是可由代理生成的逐跳请求。接收非2xx最终响应的CANCEL或ACK的SIP服务器不会像端到端请求那样对其进行质询。相反，它们在传输层或网络层检查发送取消或确认的实体是否与生成被取消或确认的请求的实体相同。
The SIP-AAA interface MUST allow transferring a wide range or set of information to be used to make an authorization decision. In particular, the SIP-AAA interface MUST allow an AAA server that is making an authorization decision to deliver the user profile to the SIP entity. Such a user profile may provide further information about the authorization decision to the SIP entity.
SIP-AAA接口必须允许传输大范围或一组用于做出授权决策的信息。特别是，SIP-AAA接口必须允许正在做出授权决策的AAA服务器将用户配置文件交付给SIP实体。这样的用户简档可以向SIP实体提供关于授权决策的进一步信息。
For instance, a SIP proxy receives an INVITE from user A addressed to user B. The SIP proxy queries an AAA server and gets the following answer: user A is authorized to call user B, as long as the requests are routed through a particular SIP proxy server C. In this case, the SIP proxy needs to use SIP loose routing techniques to forward the INVITE so that it traverses SIP proxy C before reaching user B.
例如，SIP代理从用户a接收一个发送给用户B的邀请。SIP代理查询AAA服务器并得到以下答案：只要请求通过特定的SIP代理服务器C路由，用户a就有权呼叫用户B。在这种情况下，SIP代理需要使用SIP松散路由技术转发INVITE，以便在到达用户B之前遍历SIP代理C。
The SIP-AAA interface MUST allow the AAA server to inform a SIP entity when a particular user is no longer authorized to perform a particular task, even if it is an ongoing task.
SIP-AAA接口必须允许AAA服务器在特定用户不再被授权执行特定任务时通知SIP实体，即使该任务是正在进行的任务。
The SIP-AAA interface MUST allow the AAA server to inform a SIP entity that a particular authorization has been refreshed, and therefore, the user is still authorized to perform a particular task.
SIP-AAA接口必须允许AAA服务器通知SIP实体特定授权已刷新，因此，用户仍有权执行特定任务。
The SIP-AAA interface MUST support credit control. That is, the AAA server has to be able to check the end user's account for coverage for the requested service event charge before authorizing execution of that service event. Note that this requirement is related to accounting as well.
SIP-AAA接口必须支持信用控制。也就是说，AAA服务器必须能够在授权执行该服务事件之前，检查最终用户的帐户是否覆盖了请求的服务事件费用。请注意，此要求也与会计相关。
Credit control is useful to implement prepaid services where all chargeable events related to a specific account are withheld from the end user when the credit of that account is exhausted or expired.
信用控制有助于实施预付费服务，当特定账户的信用耗尽或过期时，与该账户相关的所有收费事件都会被扣留。
This section outlines requirements on the SIP-AAA interface related to accounting. Accounting is more than simple charging. Accounting may be a simple list of services accessed, servers accessed, duration of session, etc. Charging for SIP sessions can be extremely complex and requires some additional study. It is not the intent of this section to focus on charging.
本节概述了与会计相关的SIP-AAA接口的要求。会计不仅仅是简单的收费。记帐可能是访问的服务、访问的服务器、会话持续时间等的简单列表。SIP会话的收费可能非常复杂，需要进行一些额外的研究。本节的目的不是集中讨论充电。
The information available to be accounted is different at SIP proxies and at SIP UAs. When end-to-end encryption is used, proxies do not have access to some parts of the SIP messages, while UAs have access to the whole messages. In addition to this, UAs typically have information about the session itself (e.g., number of audio packets exchanged during an audio session). Therefore, even if the SIP-AAA interface provides a means to transfer a wide range of data, some SIP nodes may not have access to it. In order to design a network, it is important to analyze which SIP nodes will be able to generate the desired account records.
在SIP代理和SIP UAs中，可用的会计信息是不同的。当使用端到端加密时，代理无法访问SIP消息的某些部分，而UAs可以访问整个消息。除此之外，UAs通常具有关于会话本身的信息（例如，在音频会话期间交换的音频数据包的数量）。因此，即使SIP-AAA接口提供了传输大范围数据的方法，一些SIP节点也可能无法访问它。为了设计网络，重要的是分析哪些SIP节点能够生成所需的帐户记录。
AAA accounting messages MUST be able to provide granular information based on different parameters.
AAA记帐消息必须能够根据不同的参数提供粒度信息。
For example, it should be possible to separate "session duration" information from other information generated via additional services (e.g., 3-way calling). Separating accounting information makes it possible to provide accounting information to different parties based upon different aspects of the session.
例如，应该可以将“会话持续时间”信息与通过附加服务（例如，3路呼叫）生成的其他信息分开。将会计信息分开可以根据会议的不同方面向不同的缔约方提供会计信息。
There MUST be support in the SIP-AAA interface for accounting transfers where the information contained in the accounting data has a direct bearing on the establishment, progression, and termination of a session (e.g., reception of a BYE request).
SIP-AAA接口必须支持会计传输，其中会计数据中包含的信息直接影响会话的建立、进展和终止（例如，接收BYE请求）。
There MUST be support in the SIP-AAA interface for accounting transfers where the information contained in the accounting data does NOT have a direct bearing on the establishment, progression, and termination of a session (e.g., an instant MESSAGE that is not related to any session).
SIP-AAA接口必须支持会计传输，其中会计数据中包含的信息对会话的建立、进行和终止没有直接影响（例如，与任何会话无关的即时消息）。
The SIP-AAA interface MUST allow SIP servers to provide relevant accounting information for billing and inter-network settlement purposes to the AAA servers. Both one-time event accounting records and session based (START, INTERIM, STOP records) accounting MUST be supported.
SIP-AAA接口必须允许SIP服务器向AAA服务器提供用于计费和网络间结算的相关会计信息。必须支持一次性事件记帐记录和基于会话（开始、临时、停止记录）的记帐。
The SIP-AAA interface MUST support accounting per media component (e.g., voice and video). That is, the SIP-AAA interface MUST be able to provide the AAA server with the types (e.g., voice and video) of the media streams of a given session.
SIP-AAA接口必须支持每个媒体组件（如语音和视频）的计费。也就是说，SIP-AAA接口必须能够向AAA服务器提供给定会话的媒体流的类型（例如，语音和视频）。
Note, however, that some SIP entities do not have access to this information, which is typically carried in session descriptions. An example of a SIP entity with access to this information is a SIP UA (e.g., a gateway towards the PSTN).
但是，请注意，一些SIP实体无权访问此信息，这通常在会话描述中进行。可以访问该信息的SIP实体的示例是SIP UA（例如，通向PSTN的网关）。
The SIP-AAA interface MUST enable different parties to be charged per media component.
SIP-AAA接口必须允许不同的方对每个媒体组件收费。
The SIP-AAA interface MUST allow AAA servers to communicate parameters for accounting generation.
SIP-AAA接口必须允许AAA服务器通信用于生成记帐的参数。
Some networks need to be able to relate accounting information to some aspect of the SIP messages involved. So, the SIP-AAA interface MUST allow the AAA server to correlate a particular AAA session with any aspect of the SIP messages. For example, an AAA server that receives accounting information about a SIP dialog may be interested in knowing the Call-ID of the SIP dialog.
一些网络需要能够将记帐信息与所涉及的SIP消息的某些方面相关联。因此，SIP-AAA接口必须允许AAA服务器将特定AAA会话与SIP消息的任何方面相关联。例如，接收关于SIP对话的记帐信息的AAA服务器可能有兴趣知道SIP对话的呼叫ID。
This section outlines some possible scenarios for SIP and AAA interaction. These are purely illustrative examples and do not impose any requirements.
本节概述了SIP和AAA交互的一些可能场景。这些仅仅是说明性的例子，没有强加任何要求。
Figure 1 shows the typical call flow between a SIP proxy that communicates to an AAA server that performs authentication and authorization. All the examples are based on this flow.
图1显示了与执行身份验证和授权的AAA服务器通信的SIP代理之间的典型调用流。所有示例都基于此流程。
SIP SIP AAA UAC Proxy Server
SIPAAA UAC代理服务器
| | |
|---METHOD---->| |
| |--Is it OK?-->|
| | |
| |<-----OK------|
| | |
| | |
| | |
|---METHOD---->| |
| |--Is it OK?-->|
| | |
| |<-----OK------|
| | |
| | |
Figure 1: Call flow over the SIP-AAA interface
图1:SIP-AAA接口上的呼叫流
The SIP proxy receives a request with certain credentials. The SIP UAC that generated the request may have included the credentials after having been challenged by the proxy using a 407 (Proxy Authentication Required) response. The SIP proxy sends a request to the AAA server asking if it is OK to provide a particular service for this request. The service may be simply routing forward the request or may consist of a more complex service. The AAA server checks that the credentials are correct (authentication), and checks the user profile. The user profile indicates that it is OK to provide the service, and responds to the SIP proxy. The SIP proxy provides the service requested by the SIP UAC.
SIP代理接收具有特定凭据的请求。生成请求的SIP UAC可能在被代理使用407（需要代理身份验证）响应质询之后包括凭证。SIP代理向AAA服务器发送请求，询问是否可以为此请求提供特定服务。服务可能只是路由转发请求，也可能由更复杂的服务组成。AAA服务器检查凭据是否正确（身份验证），并检查用户配置文件。用户配置文件表示可以提供服务，并响应SIP代理。SIP代理提供SIP UAC请求的服务。
User A wants to establish a voice session over the Internet with user B. User A wants its SIP signalling to be routed through SIP proxy C, because it provides a call log service (i.e., SIP proxy C sends an email to user A once a month with the duration of all the calls made during the month).
用户A希望通过Internet与用户B建立语音会话。用户A希望其SIP信令通过SIP代理C路由，因为它提供呼叫日志服务（即，SIP代理C每月向用户A发送一封电子邮件，其中包含当月所有呼叫的持续时间）。
SIP AAA User A Proxy C Server User B
SIP AAA用户A代理C服务器用户B
| | | |
|----INVITE----->| | |
| | | |
|<-----407-------| | |
| | | |
|------ACK------>| | |
| | | |
|----INVITE----->| | |
| |---Is this OK?-->| |
| | | |
| |<------OK--------| |
| | | |
| |---------INVITE------------------>|
| | | |
| |-Accounting msg->| |
| | | |
| | | |
|----INVITE----->| | |
| | | |
|<-----407-------| | |
| | | |
|------ACK------>| | |
| | | |
|----INVITE----->| | |
| |---Is this OK?-->| |
| | | |
| |<------OK--------| |
| | | |
| |---------INVITE------------------>|
| | | |
| |-Accounting msg->| |
| | | |
Figure 2: WLAN roaming user
图2:WLAN漫游用户
User A accesses the Internet using a WLAN access outside his home domain. User A, user B, SIP proxy C, and the home AAA server of user A are all in different domains.
用户A在其主域之外使用WLAN访问互联网。用户A、用户B、SIP代理C和用户A的家庭AAA服务器都位于不同的域中。
SIP proxy C challenges the initial INVITE from user A with a 407 (Proxy Authentication Required) response, and user A reissues the INVITE including his credentials. SIP proxy C consults user A's home AAA server, which confirms that the credentials belong to user A and that SIP proxy C can go ahead and provide its service for that call. SIP proxy C routes the INVITE forward towards user B and sends an accounting message to the AAA server, which will be used later to charge user A for the service provided by SIP proxy C.
SIP proxy C使用407（需要代理身份验证）响应质询用户A的初始邀请，用户A重新发出包含其凭据的邀请。SIP代理C咨询用户A的家庭AAA服务器，该服务器确认凭据属于用户A，并且SIP代理C可以继续并为该呼叫提供服务。SIP代理C将INVITE向前路由到用户B，并向AAA服务器发送记帐消息，该消息稍后将用于向用户A收取SIP代理C提供的服务费用。
User A is not in his home domain, but he still uses SIP proxy C (which is in user's A home domain) as the outbound proxy for an INVITE. SIP proxy C consults the home AAA server, which indicates that requests from user A have to be routed through SIP proxy D. SIP proxy C uses SIP loose routing so that the INVITE traverses D before reaching its destination. SIP proxy D will provide a call log service for user A.
用户A不在其主域中，但他仍然使用SIP代理C（位于用户A主域中）作为邀请的出站代理。SIP代理C咨询家庭AAA服务器，这表明来自用户A的请求必须通过SIP代理D路由。SIP代理C使用SIP松散路由，以便INVITE在到达其目的地之前遍历D。SIP代理D将为用户a提供呼叫日志服务。
SIP AAA SIP User A Proxy C Server Proxy D
SIP AAA SIP用户A代理C服务器代理D
| | | |
|----INVITE----->| | |
| | | |
|<-----407-------| | |
| | | |
|------ACK------>| | |
| | | |
|----INVITE----->| | |
| |------Is this OK?---->| |
| | | |
| |<-OK if routed thru D-| |
| | | |
| |---------INVITE------------------>|
| | | |
| | | |
|----INVITE----->| | |
| | | |
|<-----407-------| | |
| | | |
|------ACK------>| | |
| | | |
|----INVITE----->| | |
| |------Is this OK?---->| |
| | | |
| |<-OK if routed thru D-| |
| | | |
| |---------INVITE------------------>|
| | | |
Figure 3: Conditional Authorization
图3：有条件授权
Security is a critical requirement of the SIP-AAA Interface. Section 2.1.9 describes the threats and security requirements. Sections 2.2 and 2.3 elaborate on the authentication and authorization requirements.
安全性是SIP-AAA接口的关键要求。第2.1.9节描述了威胁和安全要求。第2.2节和第2.3节详细说明了认证和授权要求。
The authors would like to thank the participants of the SIP interim meeting, May 2002 for their comments. The authors would also thank Harri Hakala, Mary Barns, Pete McCann, Jari Arkko, Aki Niemi, Juha Heinanen, Henry Sinnreich, Allison Mankin, and Bernard Aboba for their comments.
作者要感谢2002年5月SIP临时会议的与会者提出的意见。作者还将感谢哈里·哈卡拉、玛丽·巴恩斯、皮特·麦肯、贾里·阿尔科、阿基·尼米、朱哈·海纳宁、亨利·辛里奇、埃里森·曼金和伯纳德·阿博巴的评论。
The authors would like to thank the authors of the "AAA Requirements for IP Telephony/Multimedia" document, as it provided a basis for some of the information contained in this document.
作者要感谢“IP电话/多媒体AAA要求”文件的作者，因为它为本文件中包含的一些信息提供了基础。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[3] Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.和J.Arkko，“直径基准协议”，RFC 3588，2003年9月。
[4] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.
[4] Glass，S.，Hiller，T.，Jacobs，S.和C.Perkins，“移动IP认证、授权和记帐要求”，RFC 29772000年10月。
[5] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial in User Service (RADIUS)", RFC 2865, June 2000.
[5] Rigney，C.，Willens，S.，Rubens，A.和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[6] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[6] Aboba，B.和J.Vollbrecht，“漫游中的代理链接和策略实施”，RFC 2607，1999年6月。
[7] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial in User Service (RADIUS)", RFC 3576, July 2003.
[7] Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 35762003年7月。
[8] Aboba, B., Arkko, J. and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
[8] Aboba，B.，Arkko，J.和D.Harrington，“会计管理导论”，RFC 29752000年10月。
John Loughney Nokia Itamerenkatu 11-13 00180 Helsinki Finland
芬兰赫尔辛基诺基亚伊塔梅伦卡图11-13 00180
EMail: John.Loughney@nokia.com
EMail: John.Loughney@nokia.com
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson高级信号研究实验室FIN-02420 Jorvas芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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编辑功能的资金目前由互联网协会提供。